[llvm-commits] [llvm] r160602 - in /llvm/trunk: lib/Transforms/IPO/GlobalOpt.cpp test/Transforms/GlobalOpt/2009-11-16-BrokenPerformHeapAllocSRoA.ll test/Transforms/GlobalOpt/cleanup-pointer-root-users.ll

[Duncan Sands]

Hi Nick,

>>>> Because you get to eliminate lots of stores, i.e. all those that
>>>> don't have
>>>> pointer type?
>>>
>>> I don't get it, isn't that what we do now? If the global has pointer
>>> type then
>>> all the stores have to be pointer typed or else the IR is invalid.
>>
>> maybe I misread your patch, but it seemed to me that you disable the
>> optimization for an entire global of struct type if any field in it has
>> pointer type. I'm in essence suggesting keeping the optimization for all
>> fields except those of pointer type.
>
> Of course! That makes tons of sense.
>
> Yes, we can attack this, possibly by breaking the struct apart (subject to which
> fields are read as first-class aggregates) using the existing SRoA code in
> GlobalOpt.
>
> It's non-trivial to do, even in the simple case of tracking getelementptr and
> figuring out which field is being accessed, but it can be done. Do you have a
> particular testcase in mind?

what I was imagining was much more simple minded.  The global is known only to
be written and not read.  For each store to it, determine if it is storing a
pointer [*], and if not delete the store.  So this is exactly the same as the
traditional globalopt logic, only you test the type of the stored value before
removing any particular store.  I don't see any point to sroa or even figuring
out which field is accessed.

Ciao, Duncan.

[*] It's probably important to catch the case of pointers that are converted to
integers before being stored, so for stores of integer type you probably want to
do a bit of rummaging around to see if it came from a ptrtoint.  There's lots
more that could be done, or might have to be done to be effective in practice,
but I'm sure you know all about that.