{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":665300182,"defaultBranch":"main","name":"llvm-project","ownerLogin":"kannishk","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-07-11T22:47:10.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/78703285?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1689115638.530358","currentOid":""},"activityList":{"items":[{"before":"cbb24e139d0753d755d17fbe6bfac48ab44d0721","after":"54a6cf15069e7e88125477e0b3ce1ab063c893c6","ref":"refs/heads/main","pushedAt":"2024-02-22T18:14:07.000Z","pushType":"push","commitsCount":32,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[DirectX][NFC] Use LLVM Types in DXIL Operation specifications in DXIL.td (#81692)\n\nThis change uniformly uses LLVM Types in the specification of parameter\r\ntypes and overload types of DXIL operation.\r\n\r\nUpdated (a) parameter types accordingly in the specification of existing\r\nDXILOperations and (b) DXILEmitter.","shortMessageHtmlLink":"[DirectX][NFC] Use LLVM Types in DXIL Operation specifications in DXI…"}},{"before":"dd70aef05a86bb0c1e04c49cc1bd0457ca362ce3","after":"cbb24e139d0753d755d17fbe6bfac48ab44d0721","ref":"refs/heads/main","pushedAt":"2024-02-22T14:10:25.000Z","pushType":"push","commitsCount":1723,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (#74502)\n\nNOTE: For brevity the following talks about ConstantInt but\r\neverything extends to cover ConstantFP as well.\r\n\r\nWhilst ConstantInt::get() supports the creation of vectors whereby\r\neach lane has the same value, it achieves this via other constants:\r\n\r\n * ConstantVector for fixed-length vectors\r\n * ConstantExprs for scalable vectors\r\n\r\nHowever, ConstantExprs are being deprecated and ConstantVector is\r\nnot space efficient for larger vector types. By extending ConstantInt\r\nwe can represent vector splats by only storing the underlying scalar\r\nvalue.\r\n\r\nMore specifically:\r\n\r\n * ConstantInt gains an ElementCount variant of get().\r\n * LLVMContext is extended to map ->ConstantInt.\r\n * BitcodeReader/Writer support is extended to allow vector types.\r\n\r\nWhilst this patch adds the base support, more work is required\r\nbefore it's production ready. For example, there's likely to be\r\nmany places where isa assumes a scalar type. Accordingly\r\nthe default behaviour of ConstantInt::get() remains unchanged but a\r\nset of flags are added to allow wider testing and thus help with the\r\nmigration:\r\n\r\n --use-constant-int-for-fixed-length-splat\r\n --use-constant-fp-for-fixed-length-splat\r\n --use-constant-int-for-scalable-splat\r\n --use-constant-fp-for-scalable-splat\r\n\r\nNOTE: No change is required to the bitcode format because types and\r\nvalues are handled separately.\r\n\r\nNOTE: For similar reasons as above, code generation doesn't work\r\nout-the-box.","shortMessageHtmlLink":"[LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (ll…"}},{"before":"2096e57905a20903f668848ffd11e6130bfa58e2","after":"dd70aef05a86bb0c1e04c49cc1bd0457ca362ce3","ref":"refs/heads/main","pushedAt":"2024-02-05T18:23:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[x86_64][windows][swift] do not use Swift async extended frame for wi… (#80468)\n\n…ndows x86_64\r\ntargets that use windows 64 prologue\r\n\r\nWindows x86_64 stack frame layout is currently not compatible with\r\nSwift's async extended frame, which reserves the slot right below RBP\r\n(RBP-8) for the async context pointer, as it doesn't account for the\r\nfact that a stack object in a win64 frame can be allocated at the same\r\nlocation. This can cause issues at runtime, for instance, Swift's TCA\r\ntest code has functions that fail because of this issue, as they spill a\r\nvalue to that slack slot, which then gets overwritten by a store into\r\naddress returned by the @llvm.swift.async.context.addr() intrinsic (that\r\nends up being RBP - 8), leading to an incorrect value being used at a\r\nlater point when that stack slot is being read from again. This change\r\ndrops the use of async extended frame for windows x86_64 subtargets and\r\ninstead uses the x32 based approach of allocating a separate stack slot\r\nfor the stored async context pointer.\r\n\r\nAdditionally, LLDB which is the primary consumer of the extended frame\r\nmakes assumptions like checking for a saved previous frame pointer at\r\nthe current frame pointer address, which is also incompatible with the\r\nwindows x86_64 frame layout, as the previous frame pointer is not\r\nguaranteed to be stored at the current frame pointer address. Therefore\r\nthe extended frame layout can be turned off to fix the current\r\nmiscompile without introducing regression into LLDB for windows x86_64\r\nas it already doesn't work correctly. I am still investigating what\r\nshould be made for LLDB to support using an allocated stack slot to\r\nstore the async frame context instead of being located at RBP - 8 for\r\nwindows.","shortMessageHtmlLink":"[x86_64][windows][swift] do not use Swift async extended frame for wi… ("}},{"before":"9c4e7a159b1f2228ddf146c58c2478418cd63e86","after":"2096e57905a20903f668848ffd11e6130bfa58e2","ref":"refs/heads/main","pushedAt":"2024-02-05T18:06:04.000Z","pushType":"push","commitsCount":2374,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[X86] addConstantComments - add FP16 MOVSH asm comments support","shortMessageHtmlLink":"[X86] addConstantComments - add FP16 MOVSH asm comments support"}},{"before":"9ed30012fb4f43de42ef2f265fe384d9d0b0edf2","after":"9c4e7a159b1f2228ddf146c58c2478418cd63e86","ref":"refs/heads/main","pushedAt":"2024-01-16T17:46:33.000Z","pushType":"push","commitsCount":538,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[OpenACC] Implement 'self' clause parsing on 'update'.\n\nThe update directive has its own version of 'self' that has a 'var-list'\ninstead of a 'condition' (like the serial/parallel/kernel/combined\nconstructs). This patch special cases it on 'update' to make sure we\nparse this correctly.","shortMessageHtmlLink":"[OpenACC] Implement 'self' clause parsing on 'update'."}},{"before":"68f832f56da1af0e5fc77003f640648ec7d901ad","after":"9ed30012fb4f43de42ef2f265fe384d9d0b0edf2","ref":"refs/heads/main","pushedAt":"2024-01-11T04:14:21.000Z","pushType":"push","commitsCount":1098,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[mlir][arith][nfc] Fix typos (#77700)\n\nCleanup after https://github.com/llvm/llvm-project/pull/77211","shortMessageHtmlLink":"[mlir][arith][nfc] Fix typos (llvm#77700)"}},{"before":"bde5717d4638c27614d9d4a2e53df27087a69841","after":"68f832f56da1af0e5fc77003f640648ec7d901ad","ref":"refs/heads/main","pushedAt":"2023-12-25T21:17:01.000Z","pushType":"push","commitsCount":5002,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[clang] Use StringRef::consume_front (NFC)","shortMessageHtmlLink":"[clang] Use StringRef::consume_front (NFC)"}},{"before":"876334321f842edadcc0cd4241c76b59bb888b9e","after":"bde5717d4638c27614d9d4a2e53df27087a69841","ref":"refs/heads/main","pushedAt":"2023-11-04T14:48:23.000Z","pushType":"push","commitsCount":2656,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[analyzer][NFC] Rework SVal kind representation (#71039)\n\nThe goal of this patch is to refine how the `SVal` base and sub-kinds\r\nare represented by forming one unified enum describing the possible\r\nSVals. This means that the `unsigned SVal::Kind` and the attached\r\nbit-packing semantics would be replaced by a single unified enum. This\r\nis more conventional and leads to a better debugging experience by\r\ndefault. This eases the need of using debug pretty-printers, or the use\r\nof runtime functions doing the printing for us like we do today by\r\ncalling `Val.dump()` whenever we inspect the values.\r\n\r\nPreviously, the first 2 bits of the `unsigned SVal::Kind` discriminated\r\nthe following quartet: `UndefinedVal`, `UnknownVal`, `Loc`, or `NonLoc`.\r\nThe rest of the upper bits represented the sub-kind, where the value\r\nrepresented the index among only the `Loc`s or `NonLoc`s, effectively\r\nattaching 2 meanings of the upper bits depending on the base-kind. We\r\ndon't need to pack these bits, as we have plenty even if we would use\r\njust a plan-old `unsigned char`.\r\n\r\nConsequently, in this patch, I propose to lay out all the (non-abstract)\r\n`SVal` kinds into a single enum, along with some metadata (`BEGIN_Loc`,\r\n`END_Loc`, `BEGIN_NonLoc`, `END_NonLoc`) artificial enum values, similar\r\nhow we do with the `MemRegions`.\r\n\r\nNote that in the unified `SVal::Kind` enum, to differentiate\r\n`nonloc::ConcreteInt` from `loc::ConcreteInt`, I had to prefix them with\r\n`Loc` and `NonLoc` to resolve this ambiguity.\r\nThis should not surface in general, because I'm replacing the\r\n`nonloc::Kind` enum items with `inline constexpr` global constants to\r\nmimic the original behavior - and offer nicer spelling to these enum\r\nvalues.\r\n\r\nSome `SVal` constructors were not marked explicit, which I now mark as\r\nsuch to follow best practices, and marked others as `/*implicit*/` to\r\nclarify the intent.\r\nDuring refactoring, I also found at least one function not marked\r\n`LLVM_ATTRIBUTE_RETURNS_NONNULL`, so I did that.\r\n\r\nThe `TypeRetrievingVisitor` visitor had some accidental dead code,\r\nnamely: `VisitNonLocConcreteInt` and `VisitLocConcreteInt`.\r\n\r\nPreviously, the `SValVisitor` expected visit handlers of\r\n`VisitNonLocXXXXX(nonloc::XXXXX)` and `VisitLocXXXXX(loc::XXXXX)`, where\r\nI felt that envoding `NonLoc` and `Loc` in the name is not necessary as\r\nthe type of the parameter would select the right overload anyways, so I\r\nsimplified the naming of those visit functions.\r\n\r\nThe rest of the diff is a lot of times just formatting, because\r\n`getKind()` by nature, frequently appears in switches, which means that\r\nthe whole switch gets automatically reformatted. I could probably undo\r\nthe formatting, but I didn't want to deviate from the rule unless\r\nexplicitly requested.","shortMessageHtmlLink":"[analyzer][NFC] Rework SVal kind representation (llvm#71039)"}},{"before":"ffc5ed976a47b28a7b59673614e6f0bac770c4a9","after":"876334321f842edadcc0cd4241c76b59bb888b9e","ref":"refs/heads/main","pushedAt":"2023-10-08T20:46:34.000Z","pushType":"push","commitsCount":6762,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[mlir][bufferization] Update empty_tensor_elimination transform op (#68497)\n\nThe empty tensor elimination pass semantics have changed recently: when\r\napplied to a module, the One-Shot Module Analysis is run. Otherwise, the\r\nregular One-Shot Analysis is run. The latter one is slightly different\r\nbecause it ignores function boundaries and treats function block\r\narguments as \"read-only\".\r\n\r\nThis commit updates the transform dialect op to behave in the same way.","shortMessageHtmlLink":"[mlir][bufferization] Update empty_tensor_elimination transform op (l…"}},{"before":"a709c49d75c62ecce9e5598994692546dfd1e02b","after":"ffc5ed976a47b28a7b59673614e6f0bac770c4a9","ref":"refs/heads/main","pushedAt":"2023-08-06T17:14:30.000Z","pushType":"push","commitsCount":2985,"pusher":{"login":"kannishk","name":"Kanishk Tiwari","path":"/kannishk","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/78703285?s=80&v=4"},"commit":{"message":"[AArch64][GISel] Expand handling for G_FABS to more vector types.\n\nThis now reuses the existing lowering for G_FMIN/MAX for G_FABS too, which can\nhandle more type successfully. We can hopefully reuse the same pattern action\ndefinition for other fp operations too.","shortMessageHtmlLink":"[AArch64][GISel] Expand handling for G_FABS to more vector types."}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEAlBWBAA","startCursor":null,"endCursor":null}},"title":"Activity · kannishk/llvm-project"}