> 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
This makes may_be_aliased trust TREE_ADDRESSABLE setting for
exported decls. This should make it possible for LTO to
compute more optimistic aliasing and removes the pessimization
with respective to aliasing that currently LTO brought global
(but hidden visibility) statics cause.
Bootstrapped an
41 matches
Mail list logo
