Re: "match.pd" (was: Can support TRUNC_DIV_EXPR, TRUNC_MOD_EXPR in GCC vectorization/scalar evolution -- and/or linearization?)
(resent because of mail issues on my end)
On Mon, 22 Oct 2018, Thomas Schwinge wrote:
I had a quick look at the difference, and a[j][i] remains in this form
throughout optimization. If I write instead *((*(a+j))+i) = 0; I get
j_10 = tmp_17 / 1025;
i_11 = tmp_17 % 1025;
_1 = (long unsigned int) j_10;
_2 = _1 * 1025;
_3 = (sizetype) i_11;
_4 = _2 + _3;
or for a power of 2
j_10 = tmp_17 >> 10;
i_11 = tmp_17 & 1023;
_1 = (long unsigned int) j_10;
_2 = _1 * 1024;
_3 = (sizetype) i_11;
_4 = _2 + _3;
and in both cases we fail to notice that _4 = (sizetype) tmp_17; (at least
I think that's true).
So there are missing match.pd transformations in addition to whatever
scev/ivdep/other work is needed.
With a very simplistic "match.pd" rule (not yet any special cases
checking etc.):
diff --git gcc/match.pd gcc/match.pd
index b36d7ccb5dc3..4c23116308da 100644
--- gcc/match.pd
+++ gcc/match.pd
@@ -5126,3 +5126,28 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ wide_int_to_tree (sizetype, off); })
{ swap_p ? @0 : @2; }))
{ rhs_tree; })
+
+/* Given:
+
+ j = in / N_I
+ i = in % N_I
+
+ ..., fold:
+
+ out = j * N_I + i
+
+ ..., into:
+
+ out = in
+*/
+
+/* As long as only considering N_I being INTEGER_CST (which are always second
+ argument?), probably don't need ":c" variants? */
+
+(simplify
+ (plus:c
+ (mult:c
+ (trunc_div @0 INTEGER_CST@1)
+ INTEGER_CST@1)
+ (trunc_mod @0 INTEGER_CST@1))
+ (convert @0))
You should only specify INTEGER_CST@1 on the first occurence, the others
can be just @1. (you may be interested in @@1 at some point, but that
gets tricky)
..., the original code:
int f1(int in)
{
int j = in / N_I;
int i = in % N_I;
int out = j * N_I + i;
return out;
}
... gets simplified from ("div-mod-0.c.027t.objsz1"):
f1 (int in)
{
int out;
int i;
int j;
int _1;
int _6;
:
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_return <_6>
}
... to ("div-mod-0.c.028t.ccp1"):
f1 (int in)
{
int out;
int i;
int j;
int _1;
:
gimple_assign
gimple_assign
gimple_assign
gimple_return
}
(The three dead "gimple_assign"s get eliminated later on.)
So, that works.
However, it doesn't work yet for the original construct that I'd ran
into, which looks like this:
[...]
int i;
int j;
[...]
signed int .offset.5_2;
[...]
unsigned int .offset.7_23;
unsigned int .iter.0_24;
unsigned int _25;
unsigned int _26;
[...]
unsigned int .iter.0_32;
[...]
:
# gimple_phi <.offset.5_2, .offset.5_21(8), .offset.5_30(9)>
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
[...]
Resolving the "a[j][i] = 123" we'll need to look into later.
As Marc noted above, with that changed into "*(*(a + j) + i) = 123", we
get:
[...]
int i;
int j;
long unsigned int _1;
long unsigned int _2;
sizetype _3;
sizetype _4;
sizetype _5;
int * _6;
[...]
signed int .offset.5_8;
[...]
unsigned int .offset.7_29;
unsigned int .iter.0_30;
unsigned int _31;
unsigned int _32;
[...]
:
# gimple_phi <.offset.5_8, .offset.5_27(8), .offset.5_36(9)>
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
gimple_assign
[...]
Here, unless I'm confused, "_4" is supposed to be equal to ".iter.0_30",
but "match.pd" doesn't agree yet. Note the many "nop_expr"s here, which
I have not yet figured out how to handle, I suppose? I tried some things
but couldn't get it to work. Apparently the existing instances of
"(match (nop_convert @0)" and "Basic strip-useless-type-conversions /
strip_nops" rule also don't handle these; should they? Or, are in fact
here the types mixed up too much?
"(match (nop_convert @0)" defines a shortcut so some transformations can
use nop_convert to detect some specific conversions, but it doesn't do
anything by itself. "Basic strip-useless-type-conversions" strips
conversions that are *useless*, essentially from a type to the same
type. If you want to handle true conversions, you need to do that
explicitly, see the many transformations that use convert? convert1?
convert2? and specify for which particular conversions the
transformation is valid. Finding out the right conditions to detect
these conversions is often the most painful part of writing a match.pd
transformation.
I hope to get some time again soon to continue looking into this, but if
anybody got any ideas, I'm all ears.
--
Marc Glisse
gcc-9-20181104 is now available
Snapshot gcc-9-20181104 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20181104/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 265779 You'll find: gcc-9-20181104.tar.xzComplete GCC SHA256=79dd9253c324889496bfec195ef898707ed5861ad4dc40052b9102e92ab31abf SHA1=106760bf0df6b84c72102c60cd51889774b07175 Diffs from 9-20181028 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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: confirm unsubscribe from gcc@gcc.gnu.org
-- Thierry Lavoie, B.Ing., M.Sc.A.,Ph.D. thierrylav...@fastmail.com On Sun, Nov 4, 2018, at 4:16 PM, gcc-h...@gcc.gnu.org wrote: > Hi! This is the ezmlm program. I'm managing the > gcc@gcc.gnu.org mailing list. > > To confirm that you would like > >thierry-m.lav...@polymtl.ca > > removed from the gcc mailing list, please send an empty reply > to this address: > >gcc-uc.1541376995.hmhgknfkjcoecocnccid-thierry- > m.lavoie=polymtl...@gcc.gnu.org > > Usually, this happens when you just hit the "reply" button. > If this does not work, simply copy the address and paste it into > the "To:" field of a new message. > > I haven't checked whether your address is currently on the mailing list. > To see what address you used to subscribe, look at the messages you are > receiving from the mailing list. Each message has your address hidden > inside its return path; for example, m...@xdd.ff.com receives messages > with return path: -mary=xdd.ff@gcc.gnu.org. > > Some mail programs are broken and cannot handle long addresses. If you > cannot reply to this request, instead send a message to > and put the entire address listed above > into the "Subject:" line. > > > --- Administrative commands for the gcc list --- > > I can handle administrative requests automatically. Please > do not send them to the list address! Instead, send > your message to the correct command address: > > To subscribe to the list, send a message to: > > > To remove your address from the list, send a message to: > > > Send mail to the following for info and FAQ for this list: > > > > Similar addresses exist for the digest list: > > > > To get messages 123 through 145 (a maximum of 100 per request), mail: > > > To get an index with subject and author for messages 123-456 , mail: > > > They are always returned as sets of 100, max 2000 per request, > so you'll actually get 100-499. > > To receive all messages with the same subject as message 12345, > send an empty message to: > > > The messages do not really need to be empty, but I will ignore > their content. Only the ADDRESS you send to is important. > > You can start a subscription for an alternate address, > for example "john@host.domain", just add a hyphen and your > address (with '=' instead of '@') after the command word: > > > To stop subscription for this address, mail: > > > In both cases, I'll send a confirmation message to that address. When > you receive it, simply reply to it to complete your subscription. > > If despite following these instructions, you do not get the > desired results, please contact my owner at > gcc-ow...@gcc.gnu.org. Please be patient, my owner is a > lot slower than I am ;-) > > --- Enclosed is a copy of the request I received. > > Return-Path: > Received: (qmail 121660 invoked by uid 48); 5 Nov 2018 00:16:33 - > Message-ID: <20181105001633.121657.qm...@sourceware.org> > From: anonym...@sourceware.org > Date: Mon, 05 Nov 2018 00:16:33 + > To: gcc-unsubscribe-thierry-m.lavoie=polymtl...@sourceware.org > User-Agent: Heirloom mailx 12.4 7/29/08 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > >
Re: Implementing p0515 - spaceship operator
On Wed, Sep 26, 2018 at 11:00 AM Jason Merrill wrote: > > On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote: > > I must confess that in the last months I've not been able to find much time > > (I do this in my spare time) to work on this. Part of the problem is also > > that my new employer hasn't yet provided a written copyright waiver for the > > FSF, though they have agreed and my contract already works out well in that > > regard. > > Any progress on this? Has this been worked out? We're getting near the end of GCC stage 1, which is the deadline for new features going into the next release, so it would be great to see a patch with whatever you have so far. Jason
Re: Implementing p0515 - spaceship operator
Hi Jason, I've received a lot of good advice from Nathan, but haven't had an opportunity to apply it yet. I'm happy, however, to show / commit what I have so far (which covers the parsing of the operator). I've been working from the git repository until now, but from the mailing list I gather that this is not the main development RCS yet. How and/or where would you prefer my changes to be sent to? Just as a patch to the mailing list or rather as a new branch in the SVN repo? If the latter is the case I would need a bit of assistance as it's been years since I've worked with SVN. When exactly is the feature deadline? Tim. P.S. I will make time this month to start applying Nathan's advice and push the implementation to the next step. P.P.S. The copyright situation has been resolved and I can continue contributing without issue. On 11/5/18 2:22 AM, Jason Merrill wrote: On Wed, Sep 26, 2018 at 11:00 AM Jason Merrill wrote: On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote: I must confess that in the last months I've not been able to find much time (I do this in my spare time) to work on this. Part of the problem is also that my new employer hasn't yet provided a written copyright waiver for the FSF, though they have agreed and my contract already works out well in that regard. Any progress on this? Has this been worked out? We're getting near the end of GCC stage 1, which is the deadline for new features going into the next release, so it would be great to see a patch with whatever you have so far. Jason
Re: Implementing p0515 - spaceship operator
On Mon, Nov 05, 2018 at 08:36:44AM +0100, Tim van Deurzen wrote: > I've received a lot of good advice from Nathan, but haven't had an > opportunity to apply it yet. I'm happy, however, to show / commit what I > have so far (which covers the parsing of the operator). I've been working > from the git repository until now, but from the mailing list I gather that > this is not the main development RCS yet. How and/or where would you prefer > my changes to be sent to? Just as a patch to the mailing list or rather as a > new branch in the SVN repo? If the latter is the case I would need a bit of > assistance as it's been years since I've worked with SVN. > > When exactly is the feature deadline? The deadline is end of November 11th, timezone of your choice. Patches should be just posted to gcc-patches at gcc dot gnu dot org mailing list. If you could do it today or tomorrow, it would be really appreciated. Jakub
