- User Since
- Dec 7 2016, 2:42 PM (136 w, 3 d)
Thu, Jul 18
Mar 8 2019
We need this for the internal product which is based on LLVM and there are reasons why hoisting cannot be done in our case (this is actually a different topic).
But regarding the IR expectations, I do not think there are any restrictions for alloca placement. Consider the following example
Ok. As I said earlier we need to created allocas outside of the entry block, and hoisting allocas to the entry block as Eli suggested above would definitely solve the registerization problem because of SROA, but in our case these allocas cannot be hoisted therefore SROA just does not look at them. So calling PromoteMemToReg for such allocas seems to be the only way to force registerization for them. That is the reason why I am trying to enhance it to handle bitcasts even though this functionality already exists in SROA.
Mar 7 2019
Does anyone have any comments on this match?
Feb 8 2019
[NFC] Avoid passing blocks vector to the OutlineRegionInfo constructor by value.
Feb 7 2019
Revised changes to remove extracted llvm.assume calls from the old function's assumption cache instead of clearing it.
Feb 6 2019
Removed unrelated change (lib/Transforms/IPO/PartialInlining.cpp, line 184) from the patch.
Jan 24 2019
Jan 17 2019
We use this in the internal product based on LLVM. I am not changing existing PromoteMemToReg functionality, just extending it to allow alloca use-def chain to have GEPs with zero indices and bitcasts between alloca and dependent loads/stores as long as the load/store type is bitcastable to the allocated type. This could be beneficial for the common case as well.
Jan 16 2019
I am changing PromoteMemToReg function which can be called from other places besides mem2reg pass, so this change is not limited to mem2reg pass only. Regarding SROA, it does not handle alloca instructions outside of function entry block. We need to create allocas outside of entry in some cases and the use of PromoteMemToReg() seems to be the only option for registerizing them.
This patch is a clang's part of this review https://reviews.llvm.org/D56810
Associated patch for clang tests https://reviews.llvm.org/D56811
Sep 4 2018
Ok, I will submit such patch.
Not related to this patch, but I think there is one more potentially incorrect use of containers in RTLsTy::RegisterLib(). This function may increase size of the global vector Devices when it initializes a new RTL that has not been yet used (see rtl.cpp line 219). This may result in memory reallocation and thus all pointers to the Devices elements that are stored in RTLs (see rtl.cpp line 228) would become invalid. I am not sure if these pointers are really used by RTLs now, but if yes, than it is a problem. RTLsTy::RegisterLib may be called more than once and each call may potentially initialize new RTLs.
Aug 3 2018
Replaced std::sort with llvm::sort. Added a test for offload target registration code for two offload targets.
Aug 2 2018
A simpler solution was proposed while discussing an RFC which I submitted a while ago per Alexey's request. It would lead to (almost) the same results but requires much smaller amount of changes.
Jul 18 2018
May 11 2018
Apr 27 2018
Apr 21 2018
Apr 20 2018
Aug 14 2017
Jul 17 2017
If we reached an agreement on the environment variable name and there are no more comments for this change, can it be approved?
Jun 27 2017
Jun 23 2017
Jun 7 2017
I have changed the name of environment variable which controls debugging dumps to LIBOMPTARGET_DEBUG.
Jun 5 2017
Jun 2 2017
I do not have commit access, so I cannot commit it myself. Can you please check it in?
May 31 2017
I can change the name for this environment variable it as you suggested, but it will make it consistent with other environment variable's name that is already used by libomptarget - OMP_TARGET_OFFLOAD (look at openmp/libomptarget/src/omptarget.cpp, line 285).
May 30 2017
I do not have commit access yet. Can you please check it in?
May 26 2017
I do not have commit access yet, so I cannot commit this patch myself. Can you please check it in for me?
May 24 2017
May 18 2017
Defining int DebugLevel in omptarget.cpp only would create a dependency between libomptarget.so and each plugin which I guess should be avoided. I assume we do not want to link plugins with libomptarget library.
May 16 2017
May 15 2017
Apr 27 2017
I think I do not have commit access, so I cannot commit this patch myself.