{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":642016697,"defaultBranch":"main","name":"llvm-project","ownerLogin":"agozillon","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-05-17T16:29:21.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/8973308?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1723048076.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"fe2365ea1595b85d2e3fffcb55e53b0db181c914","ref":"refs/heads/dtype-squash-rebase-v3","pushedAt":"2024-08-07T16:27:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Fix mapping nullary binding tables via checking if there is any entries, more optimal approach would be to check if theres any dispatch operations inside of the target region (save some bandwidth from unrequired maps)","shortMessageHtmlLink":"Fix mapping nullary binding tables via checking if there is any entri…"}},{"before":"047caa96e28470d128b2fb833797436a6e70644a","after":"3e411d53a2fb81608dbfd58ea5d9127abfa411f1","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-08-02T13:54:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP][Offload] Modify OMPMapInfoFinalization to work on a Module and add runtime test","shortMessageHtmlLink":"[Flang][OpenMP][Offload] Modify OMPMapInfoFinalization to work on a M…"}},{"before":null,"after":"7201a2c06e485766d655344f683a16b96ee860ec","ref":"refs/heads/dtype-squash-rebase-v2","pushedAt":"2024-07-25T17:01:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"PR for addition of addendum binding data mapping when available","shortMessageHtmlLink":"PR for addition of addendum binding data mapping when available"}},{"before":null,"after":"5c943d883d441dd115cc440d79c2130f13322e60","ref":"refs/heads/fix-for-dependent-PR","pushedAt":"2024-07-18T01:24:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][MLIR] Fix to mapping adding additional map pointer component for Descriptor mappings, helps to fix use_device_addr/ptr with these types\n\nThis PR basically adds an additional pointer binding for the descriptor base address. which we attach the user data to, it also makes sure that the mapping for the descriptor is always at a minimum \"to\" where possible, as regardless of whether or not we wish to map the user data the descriptor wrapping the data must be mapped across as the kernel will still make an attempt to access descriptor information to perform various tasks such as indexing into the user data. This may eventually be restricted a little further in the future to only allow descriptors to have a to mapping in cases where it's legal to have a to mapping (i.e. not legal on an exit directive).","shortMessageHtmlLink":"[Flang][MLIR] Fix to mapping adding additional map pointer component …"}},{"before":"07c893aa08bdc3e048dc27326a98b7d20c2e8f9f","after":"96134b2d67350af6d9516b6c77bd9c89d25cd209","ref":"refs/heads/map-clean-and-bugfix","pushedAt":"2024-07-08T13:52:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][MLIR][OpenMP] Align map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types\n\nThis PR aims unify the map argument generation across both the implicit capture (captured in a target region) and the explicit capture (process map), currently the varPtr field of the MapInfo for the same variable will be different depending on how it's captured. This PR tries to align that across the generations of MapInfoOp in the OpenMP lowering.\n\nCurrently, I have opted to utilise the rawInput (input memref to a HLFIR DeclareInfoOp) as opposed to the addr field which includes more information. The side affect of this is that we have to deal with BoxTypes less often, which will result in simpler maps in these cases. The negative side affect of this is that we don't have access to the bounds information through the resulting value, however, I believe the bounds information we require in our case is still appropriately stored in the map bounds, and this seems to be the case from testing so far.\n\nThe other fix is for cases where we end up with a BoxType argument into a function (certain assumed shape and sizes cases do this) that has no fir.ref wrapping it. As we need the Box to be a reference type to actually utilise the operation to access the base address stored inside and create the correct mappings we currently generate an intermediate allocation in these cases, and then store into it, and utilise this as the map argument, as opposed to the original.\n\nHowever, as we were not sharing the same intermediate allocation across all of the maps for a variable, this resulted in errors in certain cases when detatching/attatching the data e.g. via enter and exit.  This PR adjusts this for cases\n\nCurrently we only maintain tracking of all intermediate allocations for the current function scope, as opposed to module. Primarily as the only case I am aware of that this is required is in cases where we pass certain types of arguments to functions (so I opted to minimize the overhead of the pass for now). It could likely be extended to module scope if required if we find other cases where it's applicable and causing issues.","shortMessageHtmlLink":"[Flang][MLIR][OpenMP] Align map clause generation and fix issue with …"}},{"before":"476e4431912bb7078701f8c04df087d3610b934b","after":"047caa96e28470d128b2fb833797436a6e70644a","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-07-05T20:55:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"remove accidental extraneous newlines","shortMessageHtmlLink":"remove accidental extraneous newlines"}},{"before":"8819ac0168b73abcd27536f339cd325beb08b093","after":"476e4431912bb7078701f8c04df087d3610b934b","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-07-05T20:15:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Align  map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types\n\nThis PR aims to unify the map argument generation behavior across both the implicit capture (captured in a target region) and the explicit capture (process map), currently the varPtr field of the MapInfo for the same variable will be different depending on how it's captured. This PR tries to align that across the generations of MapInfoOp in the OpenMP lowering.\n\nCurrently, I have opted to utilise the rawInput (input memref to a HLFIR DeclareInfoOp) as opposed to the addr field which includes more information. The side affect of this is that we have to deal with BoxTypes less often, which will result in simpler maps in these cases. The negative side affect of this is that we don't have access to the bounds information through the resulting value, however, I believe the bounds information we require in our case is still appropriately stored in the map bounds, and this seems to be the case from testing so far.\n\nThe other fix is for cases where we end up with a BoxType argument into a function (certain assumed shape and sizes cases do this) that has no fir.ref wrapping it. As we need the Box to be a reference type to actually utilise the operation to access the base address stored inside and create the correct mappings we currently generate an intermediate allocation in these cases, and then store into it, and utilise this as the map argument, as opposed to the original.\n\nHowever, as we were not sharing the same intermediate allocation across all of the maps for a variable, this resulted in errors in certain cases when detatching/attatching the data e.g. via enter and exit. This PR adjusts this for cases\n\nCurrently we only maintain tracking of all intermediate allocations for the current function scope, as opposed to module. Primarily as the only case I am aware of that this is required is in cases where we pass certain types of arguments to functions (so I opted to minimize the overhead of the pass for now). It could likely be extended to module scope if required if we find other cases where it's applicable and causing issues.","shortMessageHtmlLink":"[Flang][OpenMP] Align map clause generation and fix issue with non-sh…"}},{"before":null,"after":"8819ac0168b73abcd27536f339cd325beb08b093","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-07-05T19:46:13.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Align  map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types\n\nThis PR aims to unify the map argument generation behavior across both the implicit capture (captured in a target region) and the explicit capture (process map), currently the varPtr field of the MapInfo for the same variable will be different depending on how it's captured. This PR tries to align that across the generations of MapInfoOp in the OpenMP lowering.\n\nCurrently, I have opted to utilise the rawInput (input memref to a HLFIR DeclareInfoOp) as opposed to the addr field which includes more information. The side affect of this is that we have to deal with BoxTypes less often, which will result in simpler maps in these cases. The negative side affect of this is that we don't have access to the bounds information through the resulting value, however, I believe the bounds information we require in our case is still appropriately stored in the map bounds, and this seems to be the case from testing so far.\n\nThe other fix is for cases where we end up with a BoxType argument into a function (certain assumed shape and sizes cases do this) that has no fir.ref wrapping it. As we need the Box to be a reference type to actually utilise the operation to access the base address stored inside and create the correct mappings we currently generate an intermediate allocation in these cases, and then store into it, and utilise this as the map argument, as opposed to the original.\n\nHowever, as we were not sharing the same intermediate allocation across all of the maps for a variable, this resulted in errors in certain cases when detatching/attatching the data e.g. via enter and exit. This PR adjusts this for cases\n\nCurrently we only maintain tracking of all intermediate allocations for the current function scope, as opposed to module. Primarily as the only case I am aware of that this is required is in cases where we pass certain types of arguments to functions (so I opted to minimize the overhead of the pass for now). It could likely be extended to module scope if required if we find other cases where it's applicable and causing issues.","shortMessageHtmlLink":"[Flang][OpenMP] Align map clause generation and fix issue with non-sh…"}},{"before":null,"after":"07c893aa08bdc3e048dc27326a98b7d20c2e8f9f","ref":"refs/heads/map-clean-and-bugfix","pushedAt":"2024-07-05T14:05:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"7141445d3e2992fffd913f10e119ea15410c872c","after":"b28a90e0314faab704d0ff8417adcab6f542d78f","ref":"refs/heads/stack-reclaim-alloca-addressspace","pushedAt":"2024-06-27T01:12:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][Transform] Modify stack reclaim pass to use allocation address space when generating intrinsics\n\nThis PR aims to factor in the allocation address space provided by an architectures data layout when generating the intrinsic instructions, this allows them to be lowered later with the address spaces in tow. This aligns the intrinsic creation with the LLVM IRBuilder's https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/IRBuilder.h#L1053\n\nThis is also necessary for the below example to compile for OpenMP AMD GPU and not ICE the compiler in ISEL as AMD's stackrestore and stacksave are expected to have the appropriate allocation address space for AMD GPU.\n\nprogram main\n    integer(4), allocatable :: test\n    allocate(test)\n\n!$omp target map(tofrom:test)\n    do i = 1, 10\n      test = test + 50\n    end do\n!$omp end target\n\n  deallocate(test)\nend program\n\nThe PR also fixes the issue I opened a while ago which hits the same error when compiling for AMDGPU: https://github.com/llvm/llvm-project/issues/82368\n\nAlthough, you have to have the appropriate GPU LIBC and Fortran offload runtime (both compiled for AMDGPU) added to the linker for the command or it will reach another ISEL error and ICE weirdly. But with the pre-requisites it works fine with this PR.","shortMessageHtmlLink":"[Flang][Transform] Modify stack reclaim pass to use allocation addres…"}},{"before":null,"after":"7141445d3e2992fffd913f10e119ea15410c872c","ref":"refs/heads/stack-reclaim-alloca-addressspace","pushedAt":"2024-06-27T01:11:23.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"39ddaffa5a9311f06011a9644cb96bde2fa2717d","after":"892b7254a26a2163ba91962584d3e366b7a2f667","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-25T14:54:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Update test to avoid utilisation of DeclareOp","shortMessageHtmlLink":"Update test to avoid utilisation of DeclareOp"}},{"before":"b98c4a3e5876b6f96ab3fe00d7977236f54bceb3","after":"39ddaffa5a9311f06011a9644cb96bde2fa2717d","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-24T20:04:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Remove cg-rewrite from fir-opt as it's added in a seperate PR","shortMessageHtmlLink":"Remove cg-rewrite from fir-opt as it's added in a seperate PR"}},{"before":"2fe98b9b6c6ea39e3073f615b0d60af9f14dc1e0","after":"b98c4a3e5876b6f96ab3fe00d7977236f54bceb3","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-24T20:02:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Add two more regression tests","shortMessageHtmlLink":"Add two more regression tests"}},{"before":null,"after":"eb2844fa02ca80be24c0e818815ad00c188bfcfc","ref":"refs/heads/add-pass-to-openmp-fir-test","pushedAt":"2024-06-24T18:11:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Add --cg-rewrite pass to convert-to-llvm-openmp-and-fir.fir test\n\nCurrently this is missing from the fir-opt command in this test, which\nmeans we can't use certain fir.operations inside of the test without\ncausing verification issues. As an example fir::DeclareOp, which I\nbelieve the cg-rewrite pass normally converts to fir::cg::XDeclareOp prior to\nCodeGen'ng to LLVM-IR.\n\nPerhaps, there's a reason for not including this option in the command list\noriginally that I am not aware of! But it would be helpful to enable this\npass to allow the full (or at least a wider) range of FIR operations to be\nused within the test cases.","shortMessageHtmlLink":"[Flang][OpenMP] Add --cg-rewrite pass to convert-to-llvm-openmp-and-f…"}},{"before":"288903230e13a68ec7c314a082bbd8489fc01280","after":"b4927a9e6fb1bb4c49c2153e74e66fbf99153a51","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-20T22:43:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Squashed allocatable PR","shortMessageHtmlLink":"[Flang][OpenMP] Squashed allocatable PR"}},{"before":"04fc084898199add98775a36dda066bbb7ef4133","after":"288903230e13a68ec7c314a082bbd8489fc01280","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-19T23:38:51.000Z","pushType":"push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"91e1d687834342f356e13b2aa24d34b8b9ce8e14","after":"04fc084898199add98775a36dda066bbb7ef4133","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-18T22:15:14.000Z","pushType":"push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"2ea460236ab0ad0a0363198c212b513e5960c8bd","after":"91e1d687834342f356e13b2aa24d34b8b9ce8e14","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-17T23:35:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"c6b8c06df452a6e322e88e0c321f2e99ff9f8b5d","after":"fb4cb0f1755871addac02db936fa87540542d087","ref":"refs/heads/unnamed-main-symbol-error","pushedAt":"2024-06-17T19:49:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] More elegantly handle declare target in unnamed program\n\nThis PR is related to the following issue:\n\nhttps://github.com/llvm/llvm-project/issues/63362\n\nIt tries to solve the crash (which is now slightly different, since the\nissue has been languishing for a while sorry about that I missed\nthe original issue ping).\n\nThe crash occurs due to trying to access the symbol of an undefined/unnamed main when trying to find a declare\ntarget symbol that has not been specified (but can be\nassumed based on it's residence in a function or interface).\n\nThe solution in this PR will check if we're trying to retrieve\na main symbol, and then if that is the case, we make sure\nit exists (due to being named) before we attempt to retrieve\nit, this avoids the crash.\n\nHowever, that's only part of the issue in the above example,\nthe other is the significant amount of nested directives, I\nthink we are still a little while away from handling this, I\nhave added a reduced variation of the test in the issue\nas a replicator which contains a lesser number of nesting\ndirectives. To push the issue along further, it will likely be\na case of working through a number of variations of\nnested directives in conjunction with target + parallel.\n\nHowever, this PR pushes the issue above to the point where\nthe issue encountered is identical to the following:\nhttps://github.com/llvm/llvm-project/issues/67231","shortMessageHtmlLink":"[Flang][OpenMP] More elegantly handle declare target in unnamed program"}},{"before":null,"after":"c6b8c06df452a6e322e88e0c321f2e99ff9f8b5d","ref":"refs/heads/unnamed-main-symbol-error","pushedAt":"2024-06-17T19:47:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"326afe2a318d51d6ab194930323a2baba4887130","after":"2ea460236ab0ad0a0363198c212b513e5960c8bd","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-14T21:03:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":null,"after":"5f7b0270e3a7eb9955981fa4aa0a77df4e0e1b36","ref":"refs/heads/typo-fix-in-getBaseObject","pushedAt":"2024-06-13T20:53:01.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Fix type in getBaseObject causing crashes in certain scenarios\n\nThis type would unfortunately cause code like the following to ICE, where common block symbols/names are used in a map clause:\n\nsubroutine sb()\n  implicit none\n  integer:: b, c\n  common /var/ b, c\n\n!$omp target map(tofrom: /var/)\n   b = 1\n   c = 2\n!$omp end target\nend subroutine","shortMessageHtmlLink":"[Flang][OpenMP] Fix type in getBaseObject causing crashes in certain …"}},{"before":"0c09c3a505a00d00a1f88322ab24ce5201a165dd","after":"2fe98b9b6c6ea39e3073f615b0d60af9f14dc1e0","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-13T20:16:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Adjust tests based on rebase and a silly mistake when porting test into offload folder","shortMessageHtmlLink":"Adjust tests based on rebase and a silly mistake when porting test in…"}},{"before":"996b763900c6512eece2732aeda02a4a8de885b0","after":"dc31b4fadbad143cf635aa10e75161d166d04901","ref":"refs/heads/constant-to-instruction-expansion","pushedAt":"2024-06-13T13:52:43.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Add comments to header describing new arguments","shortMessageHtmlLink":"Add comments to header describing new arguments"}},{"before":"e7807839f75c6d0297d838bb02b9d3f07282c5d1","after":"996b763900c6512eece2732aeda02a4a8de885b0","ref":"refs/heads/constant-to-instruction-expansion","pushedAt":"2024-06-12T20:40:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Revert no longer necessary alterations to MLIR test now that constant -> instruction replacement has been restricted","shortMessageHtmlLink":"Revert no longer necessary alterations to MLIR test now that constant…"}},{"before":"f3ce7c0f397a3f1910e456ce8e2765c15aa0a306","after":"e7807839f75c6d0297d838bb02b9d3f07282c5d1","ref":"refs/heads/constant-to-instruction-expansion","pushedAt":"2024-06-12T20:28:08.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Remove unnecessary brace initialization","shortMessageHtmlLink":"Remove unnecessary brace initialization"}},{"before":"c137271629b4f99156d61998ae611677ca8aecdf","after":"f3ce7c0f397a3f1910e456ce8e2765c15aa0a306","ref":"refs/heads/constant-to-instruction-expansion","pushedAt":"2024-06-12T20:07:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"restrict constant -> instruction upgrade to kernel/a specified function","shortMessageHtmlLink":"restrict constant -> instruction upgrade to kernel/a specified function"}},{"before":"cfff1a760ca9d5e4a159c1fc7ccd50158dcd8e07","after":"326afe2a318d51d6ab194930323a2baba4887130","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-11T21:53:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":null,"after":"c137271629b4f99156d61998ae611677ca8aecdf","ref":"refs/heads/constant-to-instruction-expansion","pushedAt":"2024-06-05T22:48:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[OMPIRBuilder][OpenMP][LLVM] Modify and use ReplaceConstant utility in convertTarget\n\nThis PR seeks to expand/replace the Constant -> Instruction conversion that needs to\noccur inside of the OpenMP Target kernel generation to allow kernel argument\nreplacement of uses within the kernel (cannot replace constant uses within\nconstant expressions with non-constants). It does so by making use of the new-ish\nutility convertUsersOfConstantsToInstructions which is a much more expansive version\nof what the smaller \"version\" of the function I wrote does, effectively expanding\nuses of the input argument that are constant expressions into instructions so that we\ncan replace with the appropriate kernel argument.\n\nAlso alters convertUsersOfConstantsToInstructions to optionally leave dead constants\nalone is necessary when lowering from MLIR as we cannot be sure we can remove\nthe constants at this stage, even if rewritten to instructions the ModuleTranslation\nmay maintain links to the original constants and utilise them in further lowering\nsteps (as when we're lowering the kernel, the module is still in the process\nof being lowered). This can result in unusual ICEs later. These dead constants\ncan be tidied up later (and appear to be in subsequent lowering from checking\nwith emit-llvm).\n\nThe one possible downside to this replacement is that the constant -> instruction\nrewriting is no longer constrained to within the kernel, it will expand the available\nuses of an input argument that is constant and has constant uses in the module.\nThis hasn't lowered the correctness of the examples I have tested with, however,\nit may impact performance, a possibility in the future may be to optionally\nconstrain rewrites of uses of constants in convertUsersOfConstantsToInstructions\nto a provided llvm::Function.","shortMessageHtmlLink":"[OMPIRBuilder][OpenMP][LLVM] Modify and use ReplaceConstant utility i…"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAElGV44gA","startCursor":null,"endCursor":null}},"title":"Activity · agozillon/llvm-project"}