search for: d39455

Hi Ivan, > As to my own patches pending publication, they are all for the new > TBAA format, which you said would be of no help in your case. > I actually thought they would help, but merely suggested an intermediate step while waiting for those further improvements you are working on. I would be happy to try your patches and evaluate if it helps my test case... thanks /Jonas

...ll have this field, it would be natural to make it first in the list while also making it possible to detect the new format. * Encode access sizes. This is essential for a better support for accesses to union members. This patch makes the first step in this direction: https://reviews.llvm.org/D39455 but suffers from being imprecise WRT what specific part of the union object is accessed. Given we know the offset range (the base offset together with the access size), we can determine if two accesses to members of the same union type actually overlap. * Encode type sizes. This, provided in a...

On 31/10/17 01:48, Hal Finkel wrote: > On 10/30/2017 04:57 PM, Ivan Kosarev via llvm-dev wrote: >> Hello, >> >> Consider these two TBAA access tags: >> >> !1 = !{!5, !5, i64 0} >> !3 = !{!7, !7, i64 0} >> >> !5 = !{!"A", !9} >> !7 = !{!"B", !9} > > I'd find this email less confusing if you'd write out all of

To clarify further, what this paper proposes is to use !tbaa for all kinds of accesses, including aggregate ones, so we don't need to bother trying to convert them when an aggregate access becomes a series of scalar accesses or vice versa. As I said, in most cases such conversions are not possible anyway, because !tbaa.struct tags do not refer to the type of the aggregate itself and only