search for: promotecastofallocation

Hi Matthijs, Changing PromoteCastOfAllocation to not replace aggregate allocas with non-aggregate allocas if they have GEP users sounds reasonable to me. Finding the maximum alignment is sometimes still useful though, so it would be nice to update the alignment field of the alloca even if its type is left unchanged. Dan On Sep 8, 2008, at 8...

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is a good idea, is "do it if the aligment of the new...

On Sep 23, 2008, at 4:16 AM, Matthijs Kooijman wrote: > >> and then does a load or store at the higher alignment, is >> invoking undefined behavior. The alignment attribute on a load or >> store >> is an assertion about the actual alignment of the memory. > Should this undefined behaviour be caught by the verifier, or is it > ok for it > to exist? I

Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so &g...

On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the maximum alignment...

Hi Dan, > Oh, ok. So code that takes an alloca, bitcasts the address to a higher > alignment, Since alignment is not a property of a type, I don't think you can "bitcast to a higher alignment" as such. I still understand what you mean, though :-) > and then does a load or store at the higher alignment, is > invoking undefined behavior. The alignment attribute on a load

Hello, I have come across an unusual behavior where instruction domination rule is violated "Instruction does not dominate all its uses." It concerns with StackColoring pass present at llvm/lib/CodeGen/StackColoring.cpp. I am reaching out to the LLVM community to help me understand the cause of this issue and the working of the pass. The IR produced at the end of the pass seems to be