> On June 23, 2014 6:15:10 PM CEST, Jan Hubicka wrote:
> >> I don't like this very much. It's fragile and it will be very hard
> >to
> >> detect bugs caused by it.
> >>
> >> Please don't spread uses of the DECL_NONALIASED "hack".
> >>
> >> If we are only concerned about LTO I'd rather have a in
On June 23, 2014 6:15:10 PM CEST, Jan Hubicka wrote:
>> I don't like this very much. It's fragile and it will be very hard
>to
>> detect bugs caused by it.
>>
>> Please don't spread uses of the DECL_NONALIASED "hack".
>>
>> If we are only concerned about LTO I'd rather have a in_lto_p check
>>
> I don't like this very much. It's fragile and it will be very hard to
> detect bugs caused by it.
>
> Please don't spread uses of the DECL_NONALIASED "hack".
>
> If we are only concerned about LTO I'd rather have a in_lto_p check
> in may_be_aliased and trust TREE_ADDRESSABLE there.
I do not
Hi,
On Mon, Jun 23, 2014 at 04:55:36AM +0200, Jan Hubicka wrote:
> > > On Fri, 13 Jun 2014, Jan Hubicka wrote:
> > >
> > > > >
> > > > > When you extract the address and use it. For example when you
> > > > > do auto-parallelization and outline a part of your function it
> > > > > passes arrays
On Mon, 23 Jun 2014, Jan Hubicka wrote:
> > > On Fri, 13 Jun 2014, Jan Hubicka wrote:
> > >
> > > > >
> > > > > When you extract the address and use it. For example when you
> > > > > do auto-parallelization and outline a part of your function it
> > > > > passes arrays as addresses.
> > > > >
> > On Fri, 13 Jun 2014, Jan Hubicka wrote:
> >
> > > >
> > > > When you extract the address and use it. For example when you
> > > > do auto-parallelization and outline a part of your function it
> > > > passes arrays as addresses.
> > > >
> > > > Or if you start to introduce address induction
> On Fri, 13 Jun 2014, Jan Hubicka wrote:
>
> > >
> > > When you extract the address and use it. For example when you
> > > do auto-parallelization and outline a part of your function it
> > > passes arrays as addresses.
> > >
> > > Or if you start to introduce address induction variables like
On Fri, 13 Jun 2014, Jan Hubicka wrote:
> >
> > When you extract the address and use it. For example when you
> > do auto-parallelization and outline a part of your function it
> > passes arrays as addresses.
> >
> > Or if you start to introduce address induction variables like
> > the vectoriz
>
> When you extract the address and use it. For example when you
> do auto-parallelization and outline a part of your function it
> passes arrays as addresses.
>
> Or if you start to introduce address induction variables like
> the vectorizer or IVOPTs does.
I see, nothing really done by curre
On Thu, 12 Jun 2014, Jan Hubicka wrote:
> > On Thu, 12 Jun 2014, Eric Botcazou wrote:
> >
> > > > If we want to give frontends a way to pass information that address of a
> > > > given global object is not taken (apparently useful for Ada and its
> > > > alias
> > > > attribute), then I do not t
> Btw, may_be_aliased already does that.
Indeed, and we could make use of that in Ada, at least in some cases.
> Of course one issue is that it's impossible to write a verifier that
> checks whether DECL_NONALIASED and TREE_ADDRESSABLE are "out-of-sync"
> (because by design they can be). So it's
> On Thu, 12 Jun 2014, Eric Botcazou wrote:
>
> > > If we want to give frontends a way to pass information that address of a
> > > given global object is not taken (apparently useful for Ada and its alias
> > > attribute), then I do not think we are looking for middle-end only
> > > solution.
> >
On Thu, 12 Jun 2014, Eric Botcazou wrote:
> > If we want to give frontends a way to pass information that address of a
> > given global object is not taken (apparently useful for Ada and its alias
> > attribute), then I do not think we are looking for middle-end only
> > solution.
>
> I don't fee
> If we want to give frontends a way to pass information that address of a
> given global object is not taken (apparently useful for Ada and its alias
> attribute), then I do not think we are looking for middle-end only
> solution.
I don't feel very confortable with doing that in Ada, since everyb
>
> Why not just make the change to may_be_aliased in LTO mode, with a comment
> saying that TREE_PUBLIC and DECL_EXTERNAL aren't fully correct any longer?
They are fully correct to the partition being compiled BTW.
Honza
> > Sure. Still currently TREE_ADDRESSABLE on TREE_PUBLIC/DECL_EXTERNAL
> > VAR_DECLs carries no useful information, so I consider the bit unused.
>
> I guess that's true for the middle-end in non-LTO mode at this point.
> But then the new approach shouldn't be make correctness depend on its sett
> Sure. Still currently TREE_ADDRESSABLE on TREE_PUBLIC/DECL_EXTERNAL
> VAR_DECLs carries no useful information, so I consider the bit unused.
I guess that's true for the middle-end in non-LTO mode at this point.
But then the new approach shouldn't be make correctness depend on its setting
in th
On Wed, 11 Jun 2014, Eric Botcazou wrote:
> > Because that's not the point and because it feels like a hack ;)
>
> Well, if we keep the current semantics of TREE_ADDRESSABLE and decide that
> the
> predicate for aliasing is may_be_aliased, the implementation for the latter
> becomes a detail.
> Because that's not the point and because it feels like a hack ;)
Well, if we keep the current semantics of TREE_ADDRESSABLE and decide that the
predicate for aliasing is may_be_aliased, the implementation for the latter
becomes a detail. And it would seem better/simpler to have the knowledge
On Wed, Jun 11, 2014 at 11:08 AM, Eric Botcazou wrote:
>> Note that I'm happy to revert the change.
>
> Thanks.
>
>> I am hesitant to any approach that overloads TREE_ADDRESSABLE even more.
>> It already is used for two (slightly) different things - first the
>> "old" meaning that the address of t
On Wed, Jun 11, 2014 at 10:57 AM, Eric Botcazou wrote:
>> Then why not just make the LTO front-end follow the existing semantics of
>> TREE_ADDRESSABLE and clear it when it figures out that the address is not
>> taken? That would seem the natural thing to do here.
>
> I meant "clear the TREE_PUBL
> Note that I'm happy to revert the change.
Thanks.
> I am hesitant to any approach that overloads TREE_ADDRESSABLE even more.
> It already is used for two (slightly) different things - first the
> "old" meaning that the address of the symbol is needed, second, that
> the symbol is aliased by poi
> Then why not just make the LTO front-end follow the existing semantics of
> TREE_ADDRESSABLE and clear it when it figures out that the address is not
> taken? That would seem the natural thing to do here.
I meant "clear the TREE_PUBLIC/DECL_EXTERNAL flags" of course...
--
Eric Botcazou
> In non-LTO compilation I think it would allows us to optimize bettter in the
> case address of the global symbol can not be taken by the other unit or it
> can not escape back to current unit. For C/C++ this would be for runtime
> generates symbols, like for gcov runtime (well if our initializat
On Wed, 11 Jun 2014, Jan Hubicka wrote:
> > Note that I'm happy to revert the change.
> >
> > I am hesitant to any approach that overloads TREE_ADDRESSABLE even more.
> > It already is used for two (slightly) different things - first the
> > "old" meaning that the address of the symbol is needed,
> Note that I'm happy to revert the change.
>
> I am hesitant to any approach that overloads TREE_ADDRESSABLE even more.
> It already is used for two (slightly) different things - first the
> "old" meaning that the address of the symbol is needed, second, that
> the symbol is aliased by pointers.
On Mon, 9 Jun 2014, Eric Botcazou wrote:
> > I wonder if we want toupdate the frontends to set addressable flag with new
> > sense or we want symtab to simple set addressable on all global symbols or
> > invent a new flag.
> > I would preffer the first case - it seems to make most sense to me.
>
> > I wonder if we want toupdate the frontends to set addressable flag with new
> > sense or we want symtab to simple set addressable on all global symbols or
> > invent a new flag.
> > I would preffer the first case - it seems to make most sense to me.
>
> I think you need to explain why this cha
> I wonder if we want toupdate the frontends to set addressable flag with new
> sense or we want symtab to simple set addressable on all global symbols or
> invent a new flag.
> I would preffer the first case - it seems to make most sense to me.
I think you need to explain why this change is desir
> > It is my fault here - I alwasy interpreted TREE_ADDRESSABLE this way and it
> > seems to work for C/C++ that are the frontends I usually look into.
>
> But that's not true, see the obvious C testcase I attached in this thread!
You are right - I never noticed the difference in cases I looked a
> It is my fault here - I alwasy interpreted TREE_ADDRESSABLE this way and it
> seems to work for C/C++ that are the frontends I usually look into.
But that's not true, see the obvious C testcase I attached in this thread!
--
Eric Botcazou
> > ... In this particular translation unit you mean?
>
> Yes, in the translation unit being processed.
>
> > That would be worthless information for decls also reachable from elsewhere.
>
> It's the information: ADDR_EXPR of this DECL is taken somewhere in the IL,
> it's no more or not less wo
> ... In this particular translation unit you mean?
Yes, in the translation unit being processed.
> That would be worthless information for decls also reachable from elsewhere.
It's the information: ADDR_EXPR of this DECL is taken somewhere in the IL,
it's no more or not less worthless than any
On June 7, 2014 2:06:47 PM CEST, Eric Botcazou wrote:
>> An external variable is a VAR_DECL that cannot be in a register. It
>> can be loaded into a register (or stored into), and for that its
>> address is needed. So I would expect an external variable to be
>marked
>> addressable by default.
>
>
On June 7, 2014 1:54:06 PM CEST, Steven Bosscher wrote:
>On Sat, Jun 7, 2014 at 12:59 PM, Eric Botcazou wrote:
>>> >In Ada we don't mark (external) variables as addressable if we
>don't
>>> >see their address taken.
>>>
>>> You have to (now). The testing was of course to detect this...
>>
>> Well
> An external variable is a VAR_DECL that cannot be in a register. It
> can be loaded into a register (or stored into), and for that its
> address is needed. So I would expect an external variable to be marked
> addressable by default.
"address of this is needed" historically means ADDR_EXPR of th
On Sat, Jun 7, 2014 at 12:59 PM, Eric Botcazou wrote:
>> >In Ada we don't mark (external) variables as addressable if we don't
>> >see their address taken.
>>
>> You have to (now). The testing was of course to detect this...
>
> Well, you need to define what TREE_ADDRESSABLE means now, because acc
> Hmm, I don't see this.
Usual scheduler-sensitive stuff I guess, here's the assembly I have:
movqaliasing3_pkg__pointer(%rip), %rax
testq %rax, %rax
je .L6
cmpl$5, aliasing3_pkg__block(%rip)
movl$5, (%rax)
insns #4 and #5 have been wron
On June 6, 2014 7:15:55 PM CEST, Eric Botcazou wrote:
>> Bootstrapped and tested on x86_64-unknown-linux-gnu for all
>> languages including obj-c++, ada and go (yay), applied.
>
>Something went wrong because this nevertheless introduced a regression:
>
>FAIL: gnat.dg/aliasing3.adb execution test
> Bootstrapped and tested on x86_64-unknown-linux-gnu for all
> languages including obj-c++, ada and go (yay), applied.
Something went wrong because this nevertheless introduced a regression:
FAIL: gnat.dg/aliasing3.adb execution test
In Ada we don't mark (external) variables as addressable if w
40 matches
Mail list logo
