[llvm-dev] RFC: We should stop merging allocas in the inliner

[Daniel Berlin via llvm-dev]

On Mon, Aug 1, 2016 at 10:12 AM, Xinliang David Li <xinliangli at gmail.com>
wrote:

>
> On Mon, Aug 1, 2016 at 8:58 AM, Daniel Berlin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> The existing lifetime start/end is not very well defined (by spec, or by
>> code) in what it means, so you could have nested lifetime markers if you
>> wanted.   If you made the spec well-defined, they would be meaningful (for
>> loops, etc).
>>
>> There are a number of open bugs/complaints about lifetime markers and the
>> fact that the scope is not well defined (the spec says "This intrinsic
>> indicates that before this point in the code, the value of the memory
>> pointed to by ptr is dead. This means that it is known to never be used
>> and has an undefined value. A load from the pointer that precedes this
>> intrinsic can be replaced with 'undef'.)
>>
>> "Before" is not a well-defined term :)  (the end code says after, which
>> has similar problems)
>>
>> Trivial case:
>>
>> Two block loop consists, lifetime maker at beginning
>>
>> A
>> |  ^
>> |    \
>> |    |
>> |   |
>> v /
>> B
>>
>> Lifetime marker is at top of A.
>>
>> Is B before A? (if not, are we using dominates as the definition of
>> "before", because B is a predecessor of A)
>> Does the answer change if i put a jump to B somewhere above A?
>> If we use dominates, and i put a jump there, i can make A and B dominator
>> tree siblings.  Is the pointer now invalid? :)
>>
>> etc
>>
>> I suspect what is really wanted is "i want lifetime markers to specify
>> that this thing has single-iteration scope, function scope, or SESE/SEME
>> region scope"  (or something).
>>
>
>
> Also having lifetime.start marker seems unnecessary and it makes live
> range analysis less precise actually.  One local var can have one single
> end marker and multiple implicit start markers (first uses).
>

The original goal, AFAIK, of lifetime start/end was to say "the frontend
put the alloca/etc here, but that's not really where the lifetime starts,
so please ignore anything between the thing you think is the start and the
real start".

Extend this to structures, where parts of a structure may get used but
other parts still dead for a while.


> The end marker should post-dominate all uses. Having one start marker is
> like defining a least common dominator for all the implicit starts which
> make the resulting live range strictly 'larger' than necessary.
>

Yes, it is possible to track and compute more precise ranges than the
lifetime start markers give you, *assuming* the actual placement of
variables in the IR is accurate to the original block scope (IE nothing
generates uninitialized loads to start), and you compute the ranges before
anything messes that up (IE moves the uses up) :).

Right now, i believe the lifetime start markers are what block things from
moving those loads up, because they just get deleted as undefined :)

In any case, i think this is going to derail chandler's question if we
continue on this thread and not a new one :)

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/8f8ebeea/attachment.html>