[llvm-dev] RFC: Resolving TBAA issues

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Sun Aug 20 11:30:55 PDT 2017


On 08/20/2017 12:11 PM, Daniel Berlin wrote:
>
>
>
>     Finally, the merging of TBAA is definitely going to be more
>     conservative than the merging of field offset info: If we merge a
>     load of an int and a float, we will, IIRC, go to the nearest
>     common ancestor in TBAA.   The field offset info may actually
>     still be identical between the two, but we will lose it by
>     creating/or going to the common ancestor.
>
>
> Imagine
> int - offset 4
> float - offset 4
> int - offset 12
>
> merge(first int field, float) ==
> mergeintfloat -no offset info
> You can no longer disambiguate this against second int field, even 
> though it can't possibly overlap, not for type reasons, but for offset 
> reasons.

Okay, but I don't see why we have to do that. Could we not do

merge(first int field, float) == mergeintfloat @ offset 4

(where mergeintfloat is probably char or similar)

where we keep matching offsets? Or we encode some kind of disjunction 
directly (which certainly seems reasonable to me for access merging).

Thanks again,
Hal

>
>
>
>
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/08755ac0/attachment.html>


More information about the llvm-dev mailing list