[llvm-dev] Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?

[David Blaikie via llvm-dev]

On Fri, Mar 18, 2016 at 8:46 AM, Daniel Berlin <dberlin at dberlin.org> wrote:

> I *think the argument* goes that this is a 20 or 24 byte object, so if you
> *could* put something of type PB at c-8, you'd illegally overlap with the
> object at c.
>
> Thus, there can't be an object of type PB at c-8.
>
> (IE any valid object must be sizeof(PB) away in either direction, which
> means it's not possible for c->f1_ to clobber c no matter what bar does)
>

Ah, I'm not sure just how loose no-strict-aliasing is, I figured that would
allow overlapping objects, etc? (if it allows treating memory as both an
int and a float, etc, I wouldn't've guessed it would disallow accessing
part of it as one, part as another, etc - so long as alignment was
preserved) seemed to me like that was the point, but, yeah, I really don't
know much about it.


>
>
>
> On Fri, Mar 18, 2016 at 8:24 AM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Why would computing that pointer be invalid?
>>
>> (I could imagine, if there was no object behind c to point to it would be
>> invalid - but that's a dynamic property of the program that the compiler,
>> given this code, can't prove /isn't true/ (the programmer might've
>> constructed the caller such that it does always have an object behind 'c'
>> to point to))
>>
>
>
>> On Fri, Mar 18, 2016 at 1:28 AM, Markus Trippelsdorf via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On 2016.03.17 at 16:35 -0700, Chris Lattner via llvm-dev wrote:
>>> >
>>> > > On Mar 15, 2016, at 7:58 AM, Chuang-Yu Cheng via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > Please look at this c code:
>>> > >
>>> > > typedef struct _PB {
>>> > >   void* data;  /* required.*/
>>> > >   int   f1_;
>>> > >   float f2_;
>>> > > } PB;
>>> > >
>>> > > PB** bar(PB** t);
>>> > >
>>> > > void qux(PB* c) {
>>> > >   bar(&c);              /* c is escaped because of bar */
>>> > >   c->f1_ = 0;
>>> > >   c->f2_ = 0.f;
>>> > > }
>>> > >
>>> > > // gcc-5.2.1 with -fno-strict-aliasing -O2 on x86
>>> > > call    bar
>>> > > movq    8(%rsp), %rax
>>> > > movl    $0, 8(%rax)
>>> > > movl    $0x00000000, 12(%rax)
>>> > >
>>> > > // llvm 3.9.0 with -fno-strict-aliasing -O2 on x86
>>> > > callq    bar
>>> > > movq    (%rsp), %rax
>>> > > movl    $0, 8(%rax)
>>> > > movq    (%rsp), %rax
>>> > > movl    $0, 12(%rax)
>>> > >
>>> > > You can see that llvm load "c" twice, but gcc only load "c" once.
>>> > > Of course, in bar function, you may do something very dangerous, e.g.
>>> > >
>>> > > PB** bar(PB** t) {
>>> > >    *t = (PB*) t;
>>> > > }
>>> > >
>>> > > But gcc doesn't care bar's definition.
>>> > > Is llvm too conservative, or gcc too aggressive in this pattern?
>>> >
>>> > In my opinion, in the face of -fno-strict-aliasing, GCC is being too
>>> > aggressive.  It would be interesting to hear what they think.
>>>
>>> We discussed this issue briefly on the #gcc IRC channel.
>>> Richard Biener pointed out that bar cannot make c point to &c - 8,
>>> because computing that pointer would be invalid. So c->f1_ cannot
>>> clobber c itself.
>>>
>>> --
>>> Markus
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160318/2f3e27a6/attachment.html>