On Tue, Jul 27, 2021 at 10:05 AM Richard Biener
wrote:
>
> On Sun, Jul 25, 2021 at 1:58 PM Uecker, Martin
> wrote:
> >
> >
> >
> > Hi Richard,
> >
> > here is another case where it seems that TBAA goes
> > wrong. Since this is not in a loo
On Sun, Jul 25, 2021 at 1:58 PM Uecker, Martin
wrote:
>
>
>
> Hi Richard,
>
> here is another case where it seems that TBAA goes
> wrong. Since this is not in a loop, it seems this
> is something else than what we discussed. Is
> this a known issue?
No, it's not
On Sun, Jul 25, 2021 at 1:58 PM Uecker, Martin
wrote:
>
>
>
> Hi Richard,
>
> here is another case where it seems that TBAA goes
> wrong. Since this is not in a loop, it seems this
> is something else than what we discussed. Is
> this a known issue?
>
> Best,
&g
Hi Richard,
here is another case where it seems that TBAA goes
wrong. Since this is not in a loop, it seems this
is something else than what we discussed. Is
this a known issue?
Best,
Martin
#include
#include
union u {
long x;
long long y;
};
__attribute__((noinline,noclone))
long
ng
> > > > > example relative to 10.2 with -O2. I wonder whether this
> > > > > is an intentional change and if yes, what are the rules?
> > > >
> > > > Yes, this is a fix for the long-standing PR57359 where we
> > > > failed to prese
if yes, what are the rules?
> > >
> > > Yes, this is a fix for the long-standing PR57359 where we
> > > failed to preserve the order of stores when applying store-
> > > motion.
> > >
> > > The basic rule is that stores may not be re-ordered ba
led to preserve the order of stores when applying store-motion.
> >
> > The basic rule is that stores may not be re-ordered based on
> > TBAA since a store changes the dynamic type of a memory
> > location. That notably happens for C/C++ programs re-using
> > allocated
with -O2. I wonder whether this
> > is an intentional change and if yes, what are the rules?
>
> Yes, this is a fix for the long-standing PR57359 where we
> failed to preserve the order of stores when applying store-motion.
>
> The basic rule is that stores may not be re-ordered bas
is is a fix for the long-standing PR57359 where we
failed to preserve the order of stores when applying store-motion.
The basic rule is that stores may not be re-ordered based on
TBAA since a store changes the dynamic type of a memory
location. That notably happens for C/C++ programs re-using
all
Hi Richard,
I noticed that GCC 11 has different behavior in the following
example relative to 10.2 with -O2. I wonder whether this
is an intentional change and if yes, what are the rules?
Thanks!
Martin
https://godbolt.org/z/57res7ax1
#include
#include
__attribute__((__noinline__, __weak_
> se :-).
I already have done that (PR60043)
Richard.
> Bingfeng
>
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: 03 February 2014 13:16
> To: Bingfeng Mei
> Cc: Florian Weimer; Jakub Jelinek; gcc@gcc.gnu.org
> Subject: RE
[mailto:rguent...@suse.de]
Sent: 03 February 2014 13:16
To: Bingfeng Mei
Cc: Florian Weimer; Jakub Jelinek; gcc@gcc.gnu.org
Subject: RE: No TBAA before ptr_derefs_may_alias_p?
On Mon, 3 Feb 2014, Bingfeng Mei wrote:
> For the following code, why can load be moved before store instruction?
>
On Mon, 3 Feb 2014, Bingfeng Mei wrote:
> For the following code, why can load be moved before store instruction?
> TBAA still applies even it is an anti-dependency. Somehow alias analysis
> is implemented differently in vectorization.
>
> for
> int foo (long long *
gcc@gcc.gnu.org
Subject: Re: No TBAA before ptr_derefs_may_alias_p?
On Mon, 3 Feb 2014, Richard Biener wrote:
> And note that for the case in question we
> can derive non-aliasing because with
>
> p[i] += q[i];
>
> p[i] is both read _and_ written in the same iteration thus
> i
For the following code, why can load be moved before store instruction? TBAA
still applies even it is an anti-dependency. Somehow alias analysis is
implemented differently in vectorization.
for
int foo (long long *a, short *b, int n)
{
*a = (long long)(n * 100);
return (*b) + 1000
his case
and mark the write DR with a flag so that in
vect_analyze_data_ref_dependence the _vectorizer_ could apply
TBAA to disambiguate the two DRs.
Richard.
gt; you could e.g. just look if a particular function or loop contains any
> > placement new stmts (cached in struct function and loop?) and use TBAA if
> > it isn't there.
>
> I believe the convenience of TBAA lies in the fact that you don't have to
> prove anything a
statement in the IL,
> you could e.g. just look if a particular function or loop contains any
> placement new stmts (cached in struct function and loop?) and use TBAA if
> it isn't there.
I'd say that's a hack. We've been there before and we've failed
miserab
don't use placement new that often, so e.g. by having
the placement new explicit through some special GIMPLE statement in the IL,
you could e.g. just look if a particular function or loop contains any
placement new stmts (cached in struct function and loop?) and use TBAA if
it isn't there.
t often, so e.g. by having
the placement new explicit through some special GIMPLE statement in the IL,
you could e.g. just look if a particular function or loop contains any
placement new stmts (cached in struct function and loop?) and use TBAA if
it isn't there.
Jakub
; gcc@gcc.gnu.org
Subject: RE: No TBAA before ptr_derefs_may_alias_p?
On January 31, 2014 6:01:36 PM GMT+01:00, Bingfeng Mei
wrote:
>Unfortunately this patch doesn't work because the memory dependency is
>Anti in this
>case.
>
>Why TBAA cannot handle anti- & output-
On January 31, 2014 6:01:36 PM GMT+01:00, Bingfeng Mei
wrote:
>Unfortunately this patch doesn't work because the memory dependency is
>Anti in this
>case.
>
>Why TBAA cannot handle anti- & output- dependencies? I check GCC bug
>database, and
>found pr38503 &
Unfortunately this patch doesn't work because the memory dependency is Anti in
this
case.
Why TBAA cannot handle anti- & output- dependencies? I check GCC bug database,
and
found pr38503 & pr38964. I don't fully understand it, but seems to me is
related
in handling C++
Thanks, Richard,
I will prepare a patch with test as well as filing a bug.
Bingfeng
-Original Message-
From: Richard Biener [mailto:rguent...@suse.de]
Sent: 31 January 2014 15:24
To: Bingfeng Mei; gcc@gcc.gnu.org
Subject: Re: No TBAA before ptr_derefs_may_alias_p?
On 1/31/14 4:02 PM
On 1/31/14 4:02 PM, Bingfeng Mei wrote:
> Hi,
> I got this simple example to vectorize. Somehow, GCC (4.8) generates loop
> version because
> it cannot determine alias between acc[i] write and x[i].real read. It is
> pretty obvious to me that they are not aliased based on T
Hi,
I got this simple example to vectorize. Somehow, GCC (4.8) generates loop
version because
it cannot determine alias between acc[i] write and x[i].real read. It is pretty
obvious to me that they are not aliased based on TBAA information.
typedef struct
{
short real;
short imag
On Fri, Dec 30, 2011 at 6:53 PM, Jakub Jelinek wrote:
> On Thu, Dec 29, 2011 at 04:24:31PM +, Richard Sandiford wrote:
>> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
>> anti_dependence between a load X and store Y because Y might be defining
&g
On Thu, Dec 29, 2011 at 04:24:31PM +, Richard Sandiford wrote:
> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
> anti_dependence between a load X and store Y because Y might be defining
> a new object in the same space as the object that was being read
On Thu, Dec 29, 2011 at 5:24 PM, Richard Sandiford
wrote:
> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
> anti_dependence between a load X and store Y because Y might be defining
> a new object in the same space as the object that was being read by X.
AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
anti_dependence between a load X and store Y because Y might be defining
a new object in the same space as the object that was being read by X.
But it looks like we still use component-based disambigu
> C++ for this case has a FIELD_DECL in Derived of type Base, so the
> middle-end sees d..i here (and thus also automatically
> gets the TBAA hierarchy correct by means of recording component aliases).
Ada has a _Parent FIELD_DECL in Derived (of type a subtype of Base) so it
should be a
essable.
Yes, addressable in the way that get_alias_set would not skip the
component as component_uses_parent_alias_set.
> > So, what I'd like to know is in which circumstances the Ada
> > frontend uses VIEW_CONVERT_EXPRs and what counter-measures it
> > applies to
Rs and what counter-measures it
> applies to ensure consistent TBAA.
The Ada compiler generates a lot of VIEW_CONVERT_EXPRs for conversions between
aggregate (sub)types because it generates a lot of aggregate subtypes from a
given aggregate type. These conversions are purely formal and their purpose
alias-set
being a subset of the innermost one - a relationship that V_C_E can
break.
So, what I'd like to know is in which circumstances the Ada
frontend uses VIEW_CONVERT_EXPRs and what counter-measures it
applies to ensure consistent TBAA.
Thanks,
Richard.
34 matches
Mail list logo
