RE: Regression [v850,mep...]: sign_extend in loop breaks zero-overhead loop generation
> -Original Message- > From: Jeff Law [mailto:l...@redhat.com] > Sent: 30 January 2014 15:50 > To: Paulo Matos; Andreas Schwab > Cc: gcc@gcc.gnu.org > Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks > zero-overhead > loop generation > > > > > OK, of course. Don't know what I am doing today. > > It's undefined because 'i' might overflow... I will get back to this. Thanks > for pointing this out. > When you've got it sorted out, go ahead and file a BZ, include the > regression markers so that it shows up in the searches most of us are > paying the most attention to right now. > > jeff Sure. I opened it as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Paulo Matos
Gallery
Hi, I contact you because as an artist I just launched a new online art gallery: www.harngallery.com. It connects artists and collectors around the world through a curated marketplace for affordable, original art. We offer the artists the highest commission rates (80% of the selling price). I thought you could be interested. Regards, Louis Guillaume PS: if you like the gallery you can take a look at the Facebook page: https://www.facebook.com/harngallery _ Unsubscribe / Change Profile: http://ymlp279.net/ugjsyqwbgsgbhwubbgumysggyewuym Powered by YourMailingListProvider
No TBAA before ptr_derefs_may_alias_p?
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;
} complex16_t;
void
libvector_AccSquareNorm_ref (unsigned long long *acc,
const complex16_t *x, unsigned len)
{
for (unsigned i = 0; i < len; i++)
{
acc[i] +=
((unsigned long long)((int)x[i].real * x[i].real)) +
((unsigned long long)((int)x[i].imag * x[i].imag));
}
}
Tracing into how the alias information is calculated, I found it hits the
following code
by calling ptr_derefs_may_alias_p and return true. ptr_derefs_may_alias_p
doesn't contain
TBAA disambiguation code. Should we add check before that?
/* If we had an evolution in a MEM_REF BASE_OBJECT we do not know
the size of the base-object. So we cannot do any offset/overlap
based analysis but have to rely on points-to information only. */
if (TREE_CODE (addr_a) == MEM_REF
&& DR_UNCONSTRAINED_BASE (a))
{
if (TREE_CODE (addr_b) == MEM_REF
&& DR_UNCONSTRAINED_BASE (b))
return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
TREE_OPERAND (addr_b, 0));
else
return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
build_fold_addr_expr (addr_b));
}
else if (TREE_CODE (addr_b) == MEM_REF
&& DR_UNCONSTRAINED_BASE (b))
return ptr_derefs_may_alias_p (build_fold_addr_expr (addr_a),
TREE_OPERAND (addr_b, 0));
/* Otherwise DR_BASE_OBJECT is an access that covers the whole object
that is being subsetted in the loop nest. */
if (DR_IS_WRITE (a) && DR_IS_WRITE (b))
return refs_output_dependent_p (addr_a, addr_b);
else if (DR_IS_READ (a) && DR_IS_WRITE (b))
return refs_anti_dependent_p (addr_a, addr_b);
return refs_may_alias_p (addr_a, addr_b);
This issue can be reproduced on trunk x86-64 gcc.
Cheers,
Bingfeng Mei
Re: No TBAA before ptr_derefs_may_alias_p?
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 TBAA information.
>
> typedef struct
> {
>short real;
>short imag;
> } complex16_t;
>
> void
> libvector_AccSquareNorm_ref (unsigned long long *acc,
> const complex16_t *x, unsigned len)
> {
> for (unsigned i = 0; i < len; i++)
> {
> acc[i] +=
> ((unsigned long long)((int)x[i].real * x[i].real)) +
> ((unsigned long long)((int)x[i].imag * x[i].imag));
> }
> }
>
> Tracing into how the alias information is calculated, I found it hits the
> following code
> by calling ptr_derefs_may_alias_p and return true. ptr_derefs_may_alias_p
> doesn't contain
> TBAA disambiguation code. Should we add check before that?
>
> /* If we had an evolution in a MEM_REF BASE_OBJECT we do not know
> the size of the base-object. So we cannot do any offset/overlap
> based analysis but have to rely on points-to information only. */
> if (TREE_CODE (addr_a) == MEM_REF
> && DR_UNCONSTRAINED_BASE (a))
> {
> if (TREE_CODE (addr_b) == MEM_REF
> && DR_UNCONSTRAINED_BASE (b))
> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
> TREE_OPERAND (addr_b, 0));
> else
> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
> build_fold_addr_expr (addr_b));
> }
> else if (TREE_CODE (addr_b) == MEM_REF
> && DR_UNCONSTRAINED_BASE (b))
> return ptr_derefs_may_alias_p (build_fold_addr_expr (addr_a),
> TREE_OPERAND (addr_b, 0));
>
> /* Otherwise DR_BASE_OBJECT is an access that covers the whole object
> that is being subsetted in the loop nest. */
> if (DR_IS_WRITE (a) && DR_IS_WRITE (b))
> return refs_output_dependent_p (addr_a, addr_b);
> else if (DR_IS_READ (a) && DR_IS_WRITE (b))
> return refs_anti_dependent_p (addr_a, addr_b);
> return refs_may_alias_p (addr_a, addr_b);
>
> This issue can be reproduced on trunk x86-64 gcc.
True, you can add a
if (flag_strict_aliasing
&& DR_IS_WRITE (a) && DR_IS_READ (b)
&& !alias_sets_conflict_p (get_alias_set (DR_REF (a)), get_alias_set
(DR_REF (b)))
return false;
before the ptr_derefs_may_alias_p calls. TBAA is only valid for
true dependences.
Richard.
> Cheers,
> Bingfeng Mei
>
RE: No TBAA before ptr_derefs_may_alias_p?
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, 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 TBAA information.
>
> typedef struct
> {
>short real;
>short imag;
> } complex16_t;
>
> void
> libvector_AccSquareNorm_ref (unsigned long long *acc,
> const complex16_t *x, unsigned len)
> {
> for (unsigned i = 0; i < len; i++)
> {
> acc[i] +=
> ((unsigned long long)((int)x[i].real * x[i].real)) +
> ((unsigned long long)((int)x[i].imag * x[i].imag));
> }
> }
>
> Tracing into how the alias information is calculated, I found it hits the
> following code
> by calling ptr_derefs_may_alias_p and return true. ptr_derefs_may_alias_p
> doesn't contain
> TBAA disambiguation code. Should we add check before that?
>
> /* If we had an evolution in a MEM_REF BASE_OBJECT we do not know
> the size of the base-object. So we cannot do any offset/overlap
> based analysis but have to rely on points-to information only. */
> if (TREE_CODE (addr_a) == MEM_REF
> && DR_UNCONSTRAINED_BASE (a))
> {
> if (TREE_CODE (addr_b) == MEM_REF
> && DR_UNCONSTRAINED_BASE (b))
> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
> TREE_OPERAND (addr_b, 0));
> else
> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
> build_fold_addr_expr (addr_b));
> }
> else if (TREE_CODE (addr_b) == MEM_REF
> && DR_UNCONSTRAINED_BASE (b))
> return ptr_derefs_may_alias_p (build_fold_addr_expr (addr_a),
> TREE_OPERAND (addr_b, 0));
>
> /* Otherwise DR_BASE_OBJECT is an access that covers the whole object
> that is being subsetted in the loop nest. */
> if (DR_IS_WRITE (a) && DR_IS_WRITE (b))
> return refs_output_dependent_p (addr_a, addr_b);
> else if (DR_IS_READ (a) && DR_IS_WRITE (b))
> return refs_anti_dependent_p (addr_a, addr_b);
> return refs_may_alias_p (addr_a, addr_b);
>
> This issue can be reproduced on trunk x86-64 gcc.
True, you can add a
if (flag_strict_aliasing
&& DR_IS_WRITE (a) && DR_IS_READ (b)
&& !alias_sets_conflict_p (get_alias_set (DR_REF (a)), get_alias_set
(DR_REF (b)))
return false;
before the ptr_derefs_may_alias_p calls. TBAA is only valid for
true dependences.
Richard.
> Cheers,
> Bingfeng Mei
>
RE: No TBAA before ptr_derefs_may_alias_p?
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++ new operator. But this example is pretty clear and has nothing
to
do with C++ and new statement. Isn't it too conservative to disable TBAA for
anti-
& output- dependency here?
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, 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 TBAA information.
>
> typedef struct
> {
>short real;
>short imag;
> } complex16_t;
>
> void
> libvector_AccSquareNorm_ref (unsigned long long *acc,
> const complex16_t *x, unsigned len)
> {
> for (unsigned i = 0; i < len; i++)
> {
> acc[i] +=
> ((unsigned long long)((int)x[i].real * x[i].real)) +
> ((unsigned long long)((int)x[i].imag * x[i].imag));
> }
> }
>
> Tracing into how the alias information is calculated, I found it hits the
> following code
> by calling ptr_derefs_may_alias_p and return true. ptr_derefs_may_alias_p
> doesn't contain
> TBAA disambiguation code. Should we add check before that?
>
> /* If we had an evolution in a MEM_REF BASE_OBJECT we do not know
> the size of the base-object. So we cannot do any offset/overlap
> based analysis but have to rely on points-to information only. */
> if (TREE_CODE (addr_a) == MEM_REF
> && DR_UNCONSTRAINED_BASE (a))
> {
> if (TREE_CODE (addr_b) == MEM_REF
> && DR_UNCONSTRAINED_BASE (b))
> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
> TREE_OPERAND (addr_b, 0));
> else
> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
> build_fold_addr_expr (addr_b));
> }
> else if (TREE_CODE (addr_b) == MEM_REF
> && DR_UNCONSTRAINED_BASE (b))
> return ptr_derefs_may_alias_p (build_fold_addr_expr (addr_a),
> TREE_OPERAND (addr_b, 0));
>
> /* Otherwise DR_BASE_OBJECT is an access that covers the whole object
> that is being subsetted in the loop nest. */
> if (DR_IS_WRITE (a) && DR_IS_WRITE (b))
> return refs_output_dependent_p (addr_a, addr_b);
> else if (DR_IS_READ (a) && DR_IS_WRITE (b))
> return refs_anti_dependent_p (addr_a, addr_b);
> return refs_may_alias_p (addr_a, addr_b);
>
> This issue can be reproduced on trunk x86-64 gcc.
True, you can add a
if (flag_strict_aliasing
&& DR_IS_WRITE (a) && DR_IS_READ (b)
&& !alias_sets_conflict_p (get_alias_set (DR_REF (a)), get_alias_set
(DR_REF (b)))
return false;
before the ptr_derefs_may_alias_p calls. TBAA is only valid for
true dependences.
Richard.
> Cheers,
> Bingfeng Mei
>
Re: [RFC] Offloading Support in libgomp
Looks like there is a bug (in GOMP_target lowering? or in
gomp_map_vars_existing?)
The reproducer:
#define N 1000
void foo ()
{
int *a = malloc (N * sizeof (int));
printf ("1: %p\n", a);
#pragma omp target data map(tofrom: a[0:N])
{
printf ("2: %p\n", a);
#pragma omp target
{
int i;
for (i = 0; i < N; i++)
a[i] = i;
}
printf ("3: %p\n", a);
}
printf ("4: %p\n", a);
free (a);
}
Here GOMP_target believes that the pointer 'a' has a type TOFROM, so
it sets copy_from to true for the existing mapping of the pointer 'a',
that was mapped in GOMP_target_data. Therefore the output is
incorrect:
1: [host addr]
2: [host addr]
3: [host addr]
4: [target addr]
-- Ilya
Re: [RFC] Offloading Support in libgomp
On Fri, Jan 31, 2014 at 09:18:33PM +0400, Ilya Verbin wrote:
> Looks like there is a bug (in GOMP_target lowering? or in
> gomp_map_vars_existing?)
> The reproducer:
>
> #define N 1000
>
> void foo ()
> {
> int *a = malloc (N * sizeof (int));
> printf ("1: %p\n", a);
> #pragma omp target data map(tofrom: a[0:N])
> {
> printf ("2: %p\n", a);
> #pragma omp target
> {
> int i;
> for (i = 0; i < N; i++)
> a[i] = i;
> }
> printf ("3: %p\n", a);
> }
> printf ("4: %p\n", a);
> free (a);
> }
>
> Here GOMP_target believes that the pointer 'a' has a type TOFROM, so
> it sets copy_from to true for the existing mapping of the pointer 'a',
> that was mapped in GOMP_target_data. Therefore the output is
> incorrect:
Implicit map(tofrom: a) on #pragma omp target is what the standard
requires, so I don't see a bug on the compiler side.
I'd need to go back to omp-lang endless discussions regarding the copy_from
stuff and/or discuss this further.
I'd suggest just using map(tofrom: a[0:N]) also on the #pragma omp target,
then it is clear what should happen.
Jakub
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- 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++ new operator. But this example is pretty clear and has
>nothing to
>do with C++ and new statement. Isn't it too conservative to disable
>TBAA for anti-
>& output- dependency here?
Because the gcc memory model allows the dynamic type of a memory location to
change by a store.
That in turn is the only sensible way of supporting c++ placement new.
Richard.
>
>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, 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 TBAA
>information.
>>
>> typedef struct
>> {
>>short real;
>>short imag;
>> } complex16_t;
>>
>> void
>> libvector_AccSquareNorm_ref (unsigned long long *acc,
>> const complex16_t *x, unsigned len)
>> {
>> for (unsigned i = 0; i < len; i++)
>> {
>> acc[i] +=
>> ((unsigned long long)((int)x[i].real * x[i].real)) +
>> ((unsigned long long)((int)x[i].imag * x[i].imag));
>> }
>> }
>>
>> Tracing into how the alias information is calculated, I found it hits
>the following code
>> by calling ptr_derefs_may_alias_p and return true.
>ptr_derefs_may_alias_p doesn't contain
>> TBAA disambiguation code. Should we add check before that?
>>
>> /* If we had an evolution in a MEM_REF BASE_OBJECT we do not know
>> the size of the base-object. So we cannot do any offset/overlap
>> based analysis but have to rely on points-to information only.
>*/
>> if (TREE_CODE (addr_a) == MEM_REF
>> && DR_UNCONSTRAINED_BASE (a))
>> {
>> if (TREE_CODE (addr_b) == MEM_REF
>>&& DR_UNCONSTRAINED_BASE (b))
>> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
>> TREE_OPERAND (addr_b, 0));
>> else
>> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0),
>> build_fold_addr_expr (addr_b));
>> }
>> else if (TREE_CODE (addr_b) == MEM_REF
>> && DR_UNCONSTRAINED_BASE (b))
>> return ptr_derefs_may_alias_p (build_fold_addr_expr (addr_a),
>> TREE_OPERAND (addr_b, 0));
>>
>> /* Otherwise DR_BASE_OBJECT is an access that covers the whole
>object
>> that is being subsetted in the loop nest. */
>> if (DR_IS_WRITE (a) && DR_IS_WRITE (b))
>> return refs_output_dependent_p (addr_a, addr_b);
>> else if (DR_IS_READ (a) && DR_IS_WRITE (b))
>> return refs_anti_dependent_p (addr_a, addr_b);
>> return refs_may_alias_p (addr_a, addr_b);
>>
>> This issue can be reproduced on trunk x86-64 gcc.
>
>True, you can add a
>
> if (flag_strict_aliasing
>&& DR_IS_WRITE (a) && DR_IS_READ (b)
> && !alias_sets_conflict_p (get_alias_set (DR_REF (a)), get_alias_set
>(DR_REF (b)))
> return false;
>
>before the ptr_derefs_may_alias_p calls. TBAA is only valid for
>true dependences.
>
>Richard.
>
>> Cheers,
>> Bingfeng Mei
>>
Re: [RFC] Offloading Support in libgomp
2014-01-31 Jakub Jelinek : > I'd suggest just using map(tofrom: a[0:N]) also on the #pragma omp target, > then it is clear what should happen. > > Jakub I agree that this will be clearer. But there is an example #49.1 in the document [1] with the same case. And it crashes because the pointer 'p' is overwritten after the omp target data region. [1] http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf -- Ilya
patch to fix PR59985
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 207375.
2014-01-31 Vladimir Makarov
PR bootstrap/59985
* lra-constraints.c (process_alt_operands): Update reload_sum
only on the first pass.
2014-01-31 Vladimir Makarov
PR bootstrap/59985
* gcc.target/arm/pr59985.C: New.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 207366)
+++ lra-constraints.c (working copy)
@@ -2178,7 +2178,11 @@ process_alt_operands (int only_alternati
(operand_reg[nop])]
.last_reload);
- if (last_reload > bb_reload_num)
+ /* The value of reload_sum has sense only if we
+process insns in their order. It happens only on
+the first constraints sub-pass when we do most of
+reload work. */
+ if (lra_constraint_iter == 1 && last_reload > bb_reload_num)
reload_sum += last_reload - bb_reload_num;
}
/* If this is a constant that is reloaded into the
Index: testsuite/gcc.target/arm/pr59985.C
===
--- testsuite/gcc.target/arm/pr59985.C (revision 0)
+++ testsuite/gcc.target/arm/pr59985.C (working copy)
@@ -0,0 +1,68 @@
+/* { dg-do compile } */
+/* { dg-options "-g -fcompare-debug -O2 -march=armv7-a -mtune=cortex-a9
-mfpu=vfpv3-d16 -mfloat-abi=hard" } */
+
+extern void *f1 (unsigned long, unsigned long);
+extern const struct line_map *f2 (void *, int, unsigned int, const char *,
unsigned int);
+extern unsigned int f3 (void *, unsigned int);
+extern void *v1;
+struct B { const char *s; int t; };
+struct C { unsigned u; unsigned long long v; void *w; };
+unsigned long long f4 (struct C *);
+const char *f5 (void *, unsigned int, unsigned int *);
+unsigned long long f6 (void *);
+
+static inline unsigned long long
+f7 (struct C *x, unsigned y)
+{
+ unsigned long long a, b;
+ int u = x->u;
+ a = y == 64 ? -1ULL : (1ULL << y) - 1;
+ if (u + y > 64)
+{
+ f6 (x->w);
+ x->u = y;
+ return b & a;
+}
+ b = x->v;
+ b >>= u;
+ x->u = u + y;
+ return b & a;
+}
+
+static const char *
+f8 (const char *x)
+{
+ B **a;
+ unsigned long t = __builtin_strlen (x);
+ char *b;
+ struct B *c;
+ b = (char *) f1 (t + 1, 1);
+ c = (struct B *) f1 (1, sizeof (struct B));
+ __builtin_memcpy (b, x, t + 1);
+ c->t = t;
+ struct B *d = *a;
+ return d->s;
+}
+
+unsigned int
+f9 (struct C *x, void *y)
+{
+ static const char *a;
+ static int b;
+ static int c;
+ bool d, e, f;
+ unsigned t;
+ bool prev_file = a != __null;
+ if (f7 (x, 1))
+return ((unsigned int) 0);
+ d = f7 (x, 1);
+ e = f7 (x, 1);
+ f = f7 (x, 1);
+ a = f8 (f5 (y, f4 (x), &t));
+ if (e) b = f4 (x);
+ if (f)
+if (d)
+ if (prev_file)
+f2 (v1, 1, false, __null, 0);
+ return f3 (v1, c);
+}
MIPS GCC test failure: gcc.dg/tree-ssa/ssa-dom-thread-4.c
Jeff and Richard, I was looking at the test failure of gcc.dg/tree-ssa/ssa-dom-thread-4.c on MIPS. The failure is in the scan of how many jumps are threaded which has changed from 6 to 4 on MIPS. I tracked down the change to this patch: 2013-11-19 Jeff Law * tree-ssa-threadedge.c (thread_across_edge): After threading through a joiner, allow threading a normal block requiring duplication. * tree-ssa-threadupdate.c (thread_block_1): Improve code to detect jump threading requests that would muck up the loop structures. * tree-ssa-threadupdate.c: Fix trailing whitespace. * tree-ssa-threadupdate.h: Likewise. Now my initial thought is to just change the mips scan to look for 4 'Threaded' lines instead of 6 and be done with it, but the test has a long explanation of why 6 is the right answer on MIPS and I don't know what to do with this. Even after looking at the new and old dom1 dump files I can't really explain why 4 is the right number now instead of 6. I am not sure if this is broken on arc or avr now either, I didn't see any test results from these platforms in gcc-testsuite mailing list so I am not sure if they were affected or not. I also noticed that while the dom1 dump is different the final code generation for MIPS has not changed for this test. So my question is, can either of you help me with the MIPS explanation of why 4 is the right number now and/or can I just remove the explanation and change the MIPS scan? Should I leave avr and arc alone (split them off from mips) since I have no evidence that they are failing? Steve Ellcey sell...@mips.com
