Re: Successive hoisting and AVAIL_OUT in at least one successor heuristic
On Thu, 6 May 2021 at 18:51, Michael Matz wrote:
>
> Hello,
>
> On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote:
>
> > Well, I was thinking of this test-case:
> >
> > int f(int cond1, int cond2, int cond3, int x, int y)
> > {
> > void f1();
> > void f2(int);
> > void f3();
> >
> > if (cond1)
> > f1 ();
> > else
> > {
> > if (cond2)
> > f2 (x + y);
> > else
> > f3 ();
> > }
> >
> > return x + y;
> > }
> > ...
> > And during second iteration, it hoists x + y into bb2. So we are
> > effectively hoisting x + y from bb5, bb7 into bb2, which doesn't seem to
> > benefit other two paths (bb2->bb3->bb7 and bb2->bb4->bb6->bb7) since
> > they don't contain x + y.
>
> But bb7 eventually does, so it also doesn't make those paths worse.
> That's the nature of partial redundancy elimination: it doesn't require
> benefits on all paths, only on one of them. That's in difference to full
> redundancy eliminaton.
>
> As with all hoistings it can increase register pressure. The counter
> measure to this is not to limit the hoisting (because that can have
> ripple down effects when some hoists don't happen anymore), but rather to
> tackle the register pressure problem somewhen later, in the register
> allocator (or some preparatory pass). But I'm not even sure if this is
> the reason you're wondering about how PRE hoists.
Hi Michael,
Yes, my concern was primarily w.r.t increased register pressure, and
was trying to think
of a "hack" that will disable hoisting in block if it could
potentially increase chances of spills,
offsetting it's benefit (altho the issue isn't limited to hoisting, I
was special casing it because hoisting
seems to regress a couple of benchmarks on arm and aarch64).
But yes, that doesn't look like the right approach.
Thanks,
Prathamesh
>
>
> Ciao,
> Michael.
Re: Issue with pointer types marked with scalar_storage_order
On Thu, May 06, 2021 at 04:07:52PM +0200, Eric Botcazou wrote: > > On the other hand, even the name of the attribute specifically > > refers to *scalar* types, and the C standard does classsify > > pointer types amongst the scalar type. So maybe this was > > originally intended? > > I don't think so, the feature was first implemented for Ada and, in Ada, > pointer types (called access types) are *not* scalar types. So this indeed > looks like a small oversight in the implementation. Ah, I see. > > Any comments or suggestions on what to do here? > > I'm going to conduct some testing in Ada but, barring unexpected fallout, I > would be in favor of changing the GCC implementation. It's presumably a 1- > line change in the reverse_storage_order_for_component_p predicate. Makes sense to me. Thanks for the quick fix! Tom Tromey wrote: > Ulrich> If we do want to byte-swap pointer types, then I guess we need > Ulrich> to still fix the debug info problem, which I guess would at a > Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an > Ulrich> attribute to DW_TAG_pointer_type (and then probably also > Ulrich> DW_TAG_reference_type, DW_TAG_rvalue_reference_type, > Ulrich> DW_TAG_ptr_to_member_type and possibly others). Also, the > Ulrich> implementation in GDB would need to be changed accordingly. > > Ulrich> Any comments or suggestions on what to do here? > > This kind of extension is pretty normal in DWARF, so I think it isn't a > big deal to emit it. Consumers are ordinarily expected to simply ignore > things they don't understand. Given Eric's GCC change above, this is no longer necessary now. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
GCC 8.5 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 8.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507/ ftp://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507 and shortly its mirrors. It has been generated from git revision r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.5 on Friday, May 14th.
GCC 8.5 Status Report (2021-05-07)
Status == The 8.5 branch is now frozen for the final GCC 8.5 release, the release candidate has been announced. All changes to the branch require RM approval. Quality Data Priority # Change from last report --- --- P10 - 1 P2 279 - 8 P3 28 - 4 P4 152 P5 21 --- --- Total P1-P3 307 - 13 Total 480 - 13 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-April/235871.html
OpenMP 'simd', unexpected nesting of variable declaration in bind vs. 'private' clause
Hi!
I'm currently working on an OpenACC thing, which in 'omp-low' separately
for each OpenACC 'loop' construct, collects variable declarations
referenced in 'private' clauses as well as those from inner binds
(simplified). Accidently that was also enabled for OpenMP, and for a few
testcases of OpenMP 'simd', I found unexpected nesting of variable
declaration in bind vs. 'private' clause.
I'm having a check that each variable declaration encounter has not yet
been seen for the respective context, and there are a few testcases where
this triggers, all involving OpenMP 'simd', and all seem to exhibit the
similar pattern, that in the 'gimple' dump, we have:
#pragma omp simd [...] private(D.2992)
for ([...])
{
{
const difference_type D.2992;
Notice that's a 'private' clause (created during gimplification?)
referring to a variable declaration of an *inner* bind. In our code, the
'private' clause is processed first, and then later the inner bind
visited, where we again encounter the same variable declaration, and
crash.
Eventually, I'll of course disable this OpenACC-specific processing for
OpenMP contexts, but I'd like to know if I might encounter such a
scenario also for OpenACC (haven't quickly been able to replicate, is it
maybe really specific to OpenMP 'simd'?), and secondly, whether there's
something wrong in the OpenMP 'simd' implementation?
I'm seeing this for:
- 'g++.dg/gomp/pr60682.C'
- 'libgomp.c/pr90811.c'
- 'libgomp.c++/loop-13.C'
- 'libgomp.c++/loop-14.C'
- 'libgomp.c++/loop-15.C'
- 'libgomp.fortran/examples-4/simd-2.f90'
..., and I'm attaching a few reduced testcases.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
// Reduced from 'g++.dg/gomp/pr60682.C'.
struct A
{
float a;
A () {}
};
void
foo (int x)
{
#pragma omp simd
for (int i = 0; i < x; ++i)
A a;
}
// Reduced from 'libgomp.c++/loop-13.C'.
typedef __PTRDIFF_TYPE__ ptrdiff_t;
extern "C" void abort ();
template
class I
{
public:
typedef ptrdiff_t difference_type;
I ();
~I ();
I (T *);
I (const I &);
T &operator * ();
T *operator -> ();
T &operator [] (const difference_type &) const;
I &operator = (const I &);
I &operator ++ ();
I operator ++ (int);
I &operator -- ();
I operator -- (int);
I &operator += (const difference_type &);
I &operator -= (const difference_type &);
I operator + (const difference_type &) const;
I operator - (const difference_type &) const;
template friend bool operator == (I &, I &);
template friend bool operator == (const I &, const I &);
template friend bool operator < (I &, I &);
template friend bool operator < (const I &, const I &);
template friend bool operator <= (I &, I &);
template friend bool operator <= (const I &, const I &);
template friend bool operator > (I &, I &);
template friend bool operator > (const I &, const I &);
template friend bool operator >= (I &, I &);
template friend bool operator >= (const I &, const I &);
template friend typename I::difference_type operator - (I
&, I &);
template friend typename I::difference_type operator - (const
I &, const I &);
template friend I operator + (typename I::difference_type
, const I &);
private:
T *p;
};
template I::I () : p (0) {}
template I::~I () {}
template I::I (T *x) : p (x) {}
template I::I (const I &x) : p (x.p) {}
template T &I::operator * () { return *p; }
template T *I::operator -> () { return p; }
template T &I::operator [] (const difference_type &x) const {
return p[x]; }
template I &I::operator = (const I &x) { p = x.p; return
*this; }
template I &I::operator ++ () { ++p; return *this; }
template I I::operator ++ (int) { return I (p++); }
template I &I::operator -- () { --p; return *this; }
template I I::operator -- (int) { return I (p--); }
template I &I::operator += (const difference_type &x) { p +=
x; return *this; }
template I &I::operator -= (const difference_type &x) { p -=
x; return *this; }
template I I::operator + (const difference_type &x) const {
return I (p + x); }
template I I::operator - (const difference_type &x) const {
return I (p - x); }
template bool operator == (I &x, I &y) { return x.p == y.p; }
template bool operator == (const I &x, const I &y) { return
x.p == y.p; }
template bool operator != (I &x, I &y) { return !(x == y); }
template bool operator != (const I &x, const I &y) { return
!(x == y); }
template bool operator < (I &x, I &y) { return x.p < y.p; }
template bool operator < (const I &x, const I &y) { return
x.p < y.p; }
template bool operator <= (I &x, I &y) { return x.p <= y.p; }
template bool operator <= (const I &x, const I &y) { return
x.p <= y.p; }
template bool operator > (I &x, I &y) { return x.p > y.p; }
template bool operator > (const I &x, const I &y) { return
x.p > y.p; }
template bool
Re: OpenMP 'simd', unexpected nesting of variable declaration in bind vs. 'private' clause
On Fri, May 07, 2021 at 10:20:11PM +0200, Thomas Schwinge wrote:
> Hi!
>
> I'm currently working on an OpenACC thing, which in 'omp-low' separately
> for each OpenACC 'loop' construct, collects variable declarations
> referenced in 'private' clauses as well as those from inner binds
> (simplified). Accidently that was also enabled for OpenMP, and for a few
> testcases of OpenMP 'simd', I found unexpected nesting of variable
> declaration in bind vs. 'private' clause.
>
> I'm having a check that each variable declaration encounter has not yet
> been seen for the respective context, and there are a few testcases where
> this triggers, all involving OpenMP 'simd', and all seem to exhibit the
> similar pattern, that in the 'gimple' dump, we have:
>
> #pragma omp simd [...] private(D.2992)
> for ([...])
> {
> {
> const difference_type D.2992;
>
> Notice that's a 'private' clause (created during gimplification?)
> referring to a variable declaration of an *inner* bind. In our code, the
That is intentional for TREE_ADDRESSABLE variables inside of simd, see
r10-2271-gd81ab49d0586fca0f3ee2f49c4581dd02508fcca
Even if they are local to the body, as they are addressable, we need to
ensure they are omplowered as the SIMD magic arrays, otherwise different
iterations could access the same copy and because we tell vectorizer
etc. the iterations are safe to be vectorized or even independent, we would
miscompile things.
This is the only exception when this happens and is a temporary thing from
the gimplification till OpenMP lowering/expansion.
Jakub
gcc-10-20210507 is now available
Snapshot gcc-10-20210507 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20210507/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision d7c8e6261532e7b2d16221becd5db11ded03e059 You'll find: gcc-10-20210507.tar.xz Complete GCC SHA256=f078e65003046b584a076127b928357380a7d6c275626229d97b95df21afc6e7 SHA1=f1aeeafbc50175ebfeaf305a5e0695fb9a17fa2c Diffs from 10-20210430 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 8.5 Release Candidate available from gcc.gnu.org
On 5/7/21 2:48 PM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 8.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507/ ftp://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507 and shortly its mirrors. It has been generated from git revision r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.5 on Friday, May 14th. I bootstrapped and tested on powerpc64 power 7 and 8 BE and power 8, 9, and 10 LE and saw nothing unexpected.
