Re: Use predicates for RTL objects
Segher Boessenkool writes: > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: >> On Wed, Aug 07, 2019 at 12:33:53PM -0500, Segher Boessenkool wrote: >> > On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote: >> > > I would also like to get some comments on the following idea to make the >> > > code checks more readable: I am thinking of adding >> > > bool rtx_def::is_a (enum rtx_code) const >> > > This would allow us to make all the rtx_code comparisons more readable >> > > without having to define individual macros for each. >> > > i.e., >> > > REG_P (x) => x->is_a (REG) >> > > GET_CODE (x) == PLUS => x->is_a (PLUS) >> > > GET_CODE (PATTERN (x)) == SEQUENCE => PATTERN (x)->is_a (SEQUENCE) >> > >> > That makes things much worse. Not only is it less readable (IMO), but >> > the "is_a" idiom is used to check if something is of a certain class, >> > which is not the case here. >> >> Well, the rtx_code *is* kind of a class. It determines what fields of >> the rtx are valid and what they contain etc. > > It is not a class in the C++ sense. Confusing this is not useful for > anyone. > >> > In "GET_CODE (x) == PLUS" it is clear that what the resulting machine >> > code does is cheap. With "x->is_a (PLUS)", who knows what is happening >> > below the covers! >> >> We already have, for eg, is_a (x), and there are > > Whis *is* a class. And not all of us are happy with that, but since we > don't often have to see it at all, it's not so bad. Speaking as someone who is happy about that[*]... [*] ...at least in principle. It isn't really a proper class yet because we don't construct rtx sequences as rtx_sequence objects, we just access them that way. I was a bit surprised that this was defined behaviour... > Having rtx_insn a separate type from rtx is actually useful, btw. > >> predicate macros whose implementation is more complex than checking the >> code field. You basically have to trust that it's sensibly implemented, >> i.e. that it is as efficiently implemented as it can be. > > That's not my point -- my point was that it is *obvious* the way things > are now, which is nice. > >> I don't think >> people writing RTL transformations should be overly worried about what >> machine code their predicates are generating, especially when >> they're calling the defined API for it. > > The whole *design* of RTL is based around us caring a whole lot. > >> > (And "REG_P" and similar are much shorter code to type). >> >> That is true for the ones that exist, but there are lots more that don't >> and it doesn't really make sense to add individual macros for all of >> them. > > Yes. So use GET_CODE for those? REG_P is super frequent, it is really > handy to have a macro for it. > > > If you really want to convert RTL to C++, you should start with getting > rid of rtx_format and rtx_class, and make REG_P etc. work just as they > have always done. I don't think getting rid of rtx_format and rtx_class should necessarily be the first step. The base class can still provide the traditional accessors (with runtime checking when enabled). Another option would be to start adding derived classes for certain types of rtx, and actually constructing those types of rtx with the appropriate type. It'd probably make sense to start with special- purposes rtxes like ADDRESS, DEBUG_IMPLICIT_PTR or SYMBOL_REF (which is already somewhat special). IMO the advantages of using a proper class hierarchy would be: - More static type checking. Runtime RTL checking is still seen as too expensive to enable by default even in development builds, so RTL goes unchecked most of the time. - More efficient layouts, rather than forcing every piece of information outside the header to be in a pointer-sized field. Thanks, Richard
Re: GNU Tools Cauldron 2019
On 2019-07-25 3:13 p.m., Simon Marchi wrote: > Hi again! > > This is a little reminder about the Cauldron 2019. If you plan on attending, > please > take a few minutes to send your registration (instructions are on the wiki > [1]), it > helps us greatly if you do it earlier than later. > > Also, we have received some very interesting talk and BoF submissions, but > there is > still room available. If you have worked on improving the GNU toolchain > these past > years, others are probably interested in hearing about it! If you would like > to > give a talk but don't have an abstract written yet, feel free to just send the > title/topic for now and the abstract at a later time. We have room for > full-length > talks (~45 minutes plus questions), lightning talks (~10 minutes plus > questions), > BoFs as well as developer tutorials. > > Simon > > [1] https://gcc.gnu.org/wiki/cauldron2019 Hi all, The list of talks and BoFs for the GNU Tools Cauldron 2019 has now been published, you can consult it at: https://gcc.gnu.org/wiki/cauldron2019#Abstracts Please note: - If you have sent a registration email but did not receive a confirmation, it might have fallen through the cracks, please send it again. - Same thing if you have sent a talk/BoF proposal and have not heard back, please send it again. - If you have received a confirmation for your talk/BoF, but don’t see it in the list above, it’s an error, please notify me. - If you notice a typo, a formatting problem, or would like to update the title/abstract of your talk, don’t hesitate to notify me. If you would like to attend but haven’t registered yet, it is still time to do so. Just follow the instructions here: https://gcc.gnu.org/wiki/cauldron2019#Registration In theory, this is the last time I spam the public lists about the Cauldron (for this year!), further details about the logistics will be sent prior to the event to those who registered. Thank you, Simon
Re: Use predicates for RTL objects
On 8/7/19 12:05 PM, Segher Boessenkool wrote: > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: >> On Wed, Aug 07, 2019 at 12:33:53PM -0500, Segher Boessenkool wrote: >>> On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote: I would also like to get some comments on the following idea to make the code checks more readable: I am thinking of adding bool rtx_def::is_a (enum rtx_code) const This would allow us to make all the rtx_code comparisons more readable without having to define individual macros for each. i.e., REG_P (x) => x->is_a (REG) GET_CODE (x) == PLUS => x->is_a (PLUS) GET_CODE (PATTERN (x)) == SEQUENCE => PATTERN (x)->is_a (SEQUENCE) >>> >>> That makes things much worse. Not only is it less readable (IMO), but >>> the "is_a" idiom is used to check if something is of a certain class, >>> which is not the case here. >> >> Well, the rtx_code *is* kind of a class. It determines what fields of >> the rtx are valid and what they contain etc. > > It is not a class in the C++ sense. Confusing this is not useful for > anyone. True, but they could be. When David was working in this space a few years ago I concluded that the main value in sub-classing the various RTL operators just wansn't worth the effort. Instead we focused on starting to tear apart things like the toplevel objects into rtx_insn and the like. THere's little value in treating those as simple RTXs. INSN_LIST and the like were also ripe for this treatment. The biggest value in making a real class for the operators things would be to move the runtime RTL checking into a compile-time check. But I couldn't really green light something like that without first completing the rtx_insn changes. > > > If you really want to convert RTL to C++, you should start with getting > rid of rtx_format and rtx_class, and make REG_P etc. work just as they > have always done. Yup. And continue pushing the rtx_insn bits deeper, tackling INSN_LIST, etc. jeff
Re: GCC 9.2 Status Report (2019-08-05), branch frozen for release
Status == The first 9.2 release candidate has been released. The GCC 9 branch is frozen for preparation of the GCC 9.2 release. All changes to the branch now require release manager approval. Hi, Jakub. If at all possible, I'd like to request that a back port of PR c++/88095 [1] be included in the gcc 9.2 release. The rationale for including this is that it is required for one of the approaches discussed in P1423 [2] (see [3]) that may be useful for some programmers to mitigate backward compatibility impact from the adoption of char8_t in C++20 via P0482 [4]. Having this feature working in 9.2 would give impacted programmers more time to evaluate their C++20 migration options. The patch has already been integrated in trunk [5]. I verified that it applies cleanly against the gcc-9-branch (with the exception of the ChangeLog changes), and that tests complete successfully on Linux x86_64. There are no target dependencies involved in this change. Tom. [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 [2]: http://wg21.link/p1423 [3]: http://wg21.link/p1423#emulate [4]: http://wg21.link/p0482 [5]: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274123
Re: Use predicates for RTL objects
On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote: > > > > code does is cheap. With "x->is_a (PLUS)", who knows what is happening > > That's not my point -- my point was that it is *obvious* the way things > > are now, which is nice. > > My reply is pointing out that it is just as (non-)obvious with or > without that inline function, if you want to use any of the helper > macros. But that is not what you suggested, or at least not how I read it. x->is_a (PLUS) is not obviously cheap or simple at all, while GET_CODE (x) == PLUS obviously *is*. The former also isn't readable. Indirection is *the* evil in programming. All the common stuff that can be easily hidden behind macros, sure, but we're not talking only about that. And if macros have non-trivial implementations, they shouldn't be macros (but inlines), or maybe shouldn't even exist at all. > > > I don't think > > > people writing RTL transformations should be overly worried about what > > > machine code their predicates are generating, especially when > > > they're calling the defined API for it. > > > > The whole *design* of RTL is based around us caring a whole lot. > > I'm not saying that we don't care about performance. That is now what I said, either. Performance is only one aspect of simplicity. Segher
Re: GCC 9.2 Status Report (2019-08-05), branch frozen for release
On Thu, Aug 08, 2019 at 10:49:41AM -0400, Tom Honermann wrote: > > Status > > == > > > > The first 9.2 release candidate has been released. > > The GCC 9 branch is frozen for preparation of the GCC 9.2 release. > > All changes to the branch now require release manager approval. > > Hi, Jakub. If at all possible, I'd like to request that a back port of PR > c++/88095 [1] be included in the gcc 9.2 release. I'd prefer to defer it for 9.2.1 (i.e. commit after Monday next week), the fix has been on the trunk only for 3 days and would require another release candidate, plus it isn't really a regression. That way if it breaks something we have several months to discover it and fix it. Jakub
Re: Use predicates for RTL objects
Hi, On Wed, 7 Aug 2019, Arvind Sankar wrote: > => x->is_a (REG) Oh god, please no. Currently at least the RTL parts of GCC still have mostly a consistent and obvious style, which is a good thing. I have no idea why anyone would think the above is easier to read than REG_P (x). Ciao, Michael. P.S: Consider this: the current style served us quite well for the last 35 or so years, so before suggesting style changes, shouldn't you first work on the sources for some time?
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 10:10:38AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: > >> We already have, for eg, is_a (x), and there are > > > > Whis *is* a class. And not all of us are happy with that, but since we > > don't often have to see it at all, it's not so bad. > > Speaking as someone who is happy about that[*]... > > [*] ...at least in principle. It isn't really a proper class yet > because we don't construct rtx sequences as rtx_sequence objects, > we just access them that way. I was a bit surprised that this > was defined behaviour... _In principle_, sure, I have nothing against C++ conversions if it has advantages that outweigh their disadvantages. > > If you really want to convert RTL to C++, you should start with getting > > rid of rtx_format and rtx_class, and make REG_P etc. work just as they > > have always done. > > I don't think getting rid of rtx_format and rtx_class should > necessarily be the first step. The base class can still provide > the traditional accessors (with runtime checking when enabled). It is *the* core thing that needs to be changed if you want this to be any other than pointless uglification. Those two RTX fields are the core of how it works now. If you want to use C++ classes, instead, you need to replace them with some suitable C++ thing. And we need to see that design before we can say if it looks acceptable at all. > Another option would be to start adding derived classes for certain > types of rtx, and actually constructing those types of rtx with the > appropriate type. It'd probably make sense to start with special- > purposes rtxes like ADDRESS, DEBUG_IMPLICIT_PTR or SYMBOL_REF (which > is already somewhat special). I would prefer to see an overall design before making partial changes. > IMO the advantages of using a proper class hierarchy would be: > > - More static type checking. Runtime RTL checking is still seen as too > expensive to enable by default even in development builds, so RTL goes > unchecked most of the time. Many people enable it all the time. It isn't so expensive compared to other things. --enable-checking=yes,rtl,tree saves more time than it costs, ime, and "rtl" is not the most expensive in that. > - More efficient layouts, rather than forcing every piece of information > outside the header to be in a pointer-sized field. ... and then the GC has to be tuned again. Oh joy. Well, it probably is much detuned already, but :-) It would be nice to see real numbers how much memory this would save, and what that means for compiler runtime. Segher
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 08:31:28AM -0600, Jeff Law wrote: > On 8/7/19 12:05 PM, Segher Boessenkool wrote: > > It is not a class in the C++ sense. Confusing this is not useful for > > anyone. > True, but they could be. But then it would say is_a (rtx_plus) or similar. We don't have classes called "PLUS" :-) > When David was working in this space a few > years ago I concluded that the main value in sub-classing the various > RTL operators just wansn't worth the effort. Instead we focused on > starting to tear apart things like the toplevel objects into rtx_insn > and the like. THere's little value in treating those as simple RTXs. > INSN_LIST and the like were also ripe for this treatment. Yup. And there still are various casts around, so even this conversion still isn't complete (but it is not bad at all :-) ) > The biggest value in making a real class for the operators things would > be to move the runtime RTL checking into a compile-time check. That ignores 90% of the errors RTL checking catches: memory corruption. > > If you really want to convert RTL to C++, you should start with getting > > rid of rtx_format and rtx_class, and make REG_P etc. work just as they > > have always done. > Yup. And continue pushing the rtx_insn bits deeper, tackling INSN_LIST, > etc. I'm all for it. What I do *not* want to see is a partial conversion to C++ classes, doing the easy bits, and leaving a gigantic mess for everything else. Segher
Re: GCC 9.2 Status Report (2019-08-05), branch frozen for release
On 8/8/19 11:04 AM, Jakub Jelinek wrote: On Thu, Aug 08, 2019 at 10:49:41AM -0400, Tom Honermann wrote: Status == The first 9.2 release candidate has been released. The GCC 9 branch is frozen for preparation of the GCC 9.2 release. All changes to the branch now require release manager approval. Hi, Jakub. If at all possible, I'd like to request that a back port of PR c++/88095 [1] be included in the gcc 9.2 release. I'd prefer to defer it for 9.2.1 (i.e. commit after Monday next week), the fix has been on the trunk only for 3 days and would require another release candidate, plus it isn't really a regression. That way if it breaks something we have several months to discover it and fix it. I'm content with that. Thanks, Jakub. Tom. Jakub
Re: Indirect memory addresses vs. lra
On 2019-08-04 3:18 p.m., John Darrington wrote:
I'm trying to write a back-end for an architecture (s12z - the ISA you can
download from [1]). This arch accepts indirect memory addresses. That is to
say, those of the form (mem (mem (...))) and although my
TARGET_LEGITIMATE_ADDRESS
function returns true for such addresses, LRA insists on reloading them out of
existence.
For example, when compiling a code fragment:
volatile unsigned char *led = 0x2F2;
*led = 1;
the ira dump file shows:
(insn 7 6 8 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
(const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
(nil))
(insn 8 7 14 2 (set (mem/v:QI (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]) [0
*led_7+0 S1 A8])
(const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
(nil))
which is a perfectly valid insn, and the most efficient assembler for it is:
mov.p #0x2f2, y
mov.b #1, [0,y]
However the reload dump shows this has been changed to:
(insn 7 6 22 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
(const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
(nil))
(insn 22 7 8 2 (set (reg:PSI 8 x [22])
(mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]))
"/home/jmd/MemMem/memmem.c":16:8 96 {movpsi}
(nil))
(insn 8 22 14 2 (set (mem/v:QI (reg:PSI 8 x [22]) [0 *led_7+0 S1 A8])
(const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
(nil))
and ends up as:
mov.p #0x2f2, y
mov.p (0,y) x
mov.b #1, (0,x)
So this wastes a register (which leads to other issues which I don't want to go
into in this email).
After a lot of debugging I tracked down the part of lra which is doing this
reload to the function process_addr_reg at lra-constraints.c:1378
if (! REG_P (reg))
{
if (check_only_p)
return true;
/* Always reload memory in an address even if the target supports such
addresses. */
new_reg = lra_create_new_reg_with_unique_value (mode, reg, cl,
"address");
before_p = true;
}
Changing this to
if (! REG_P (reg))
{
if (check_only_p)
return true;
return false;
}
solves my immediate problem. However I imagine there was a reason for doing
this reload, and presumably a better way of avoiding it.
Can someone explain the reason for this reload, and how I can best ensure that
indirect memory operands are left in the compiled code?
The old reload (reload[1].c) supports such addressing. As modern
mainstream architectures have no this kind of addressing, it was not
implemented in LRA.
I don't think the above simple change will work fully. For example, you
need to constrain memory nesting. The constraints should be described,
may be some hooks should be implemented (may be not and
TARGET_LEGITIMATE_ADDRESS will be enough), may be additional address
anslysis and transformations should be implemented in LRA, etc. But may
be implementing this is not hard either.
It is also difficult for me to say is it worth to do. Removing such
addressing helps to remove redundant memory reads. On the other hand,
its usage can decrease #insns and save registers for better RA and
utilize hardware on design of which a lot of efforts were spent.
In any case, if somebody implements this, it can be included in LRA.
[1] https://www.nxp.com/docs/en/reference-manual/S12ZCPU_RM_V1.pdf
Re: Indirect memory addresses vs. lra
> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: > > > On 2019-08-04 3:18 p.m., John Darrington wrote: >> I'm trying to write a back-end for an architecture (s12z - the ISA you can >> download from [1]). This arch accepts indirect memory addresses. That is >> to >> say, those of the form (mem (mem (...))) and although my >> TARGET_LEGITIMATE_ADDRESS >> function returns true for such addresses, LRA insists on reloading them out >> of >> existence. >> ... > The old reload (reload[1].c) supports such addressing. As modern mainstream > architectures have no this kind of addressing, it was not implemented in LRA. Is LRA only intended for "modern mainstream architectures"? If yes, why is the old reload being deprecated? You can't have it both ways. Unless you want to obsolete all "not modern mainstream architectures" in GCC, it doesn't make sense to get rid of core functionality used by those architectures. Indirect addressing is a key feature in size-optimized code. paul
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 08:31:28AM -0600, Jeff Law wrote: > True, but they could be. When David was working in this space a few > years ago I concluded that the main value in sub-classing the various > RTL operators just wansn't worth the effort. Instead we focused on > starting to tear apart things like the toplevel objects into rtx_insn > and the like. THere's little value in treating those as simple RTXs. > INSN_LIST and the like were also ripe for this treatment. > > The biggest value in making a real class for the operators things would > be to move the runtime RTL checking into a compile-time check. But I > couldn't really green light something like that without first completing > the rtx_insn changes. Are there any notes or old discussion threads on what remains? I would be interested in taking a look if no-one else is. Thanks > > > > > > > If you really want to convert RTL to C++, you should start with getting > > rid of rtx_format and rtx_class, and make REG_P etc. work just as they > > have always done. > Yup. And continue pushing the rtx_insn bits deeper, tackling INSN_LIST, > etc. > > jeff
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote: > Hi, > > On Wed, 7 Aug 2019, Arvind Sankar wrote: > > > => x->is_a (REG) > > Oh god, please no. Currently at least the RTL parts of GCC still have > mostly a consistent and obvious style, which is a good thing. I have no > idea why anyone would think the above is easier to read than REG_P (x). > > > Ciao, > Michael. > P.S: Consider this: the current style served us quite well for the last 35 > or so years, so before suggesting style changes, shouldn't you first work > on the sources for some time? Well, the main point of the email was to ask for review of a patchset that attempts to make progress on a TODO that has been outstanding for at least 15 of those 35 years.
Re: Indirect memory addresses vs. lra
On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: > > On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: > > The old reload (reload[1].c) supports such addressing. As modern > > mainstream architectures have no this kind of addressing, it was not > > implemented in LRA. > > Is LRA only intended for "modern mainstream architectures"? I sure hope not! But it has only been *used* and *tested* much on such, so far. Things are designed to work well for modern archs. > If yes, why is the old reload being deprecated? You can't have it both ways. > Unless you want to obsolete all "not modern mainstream architectures" in > GCC, it doesn't make sense to get rid of core functionality used by those > architectures. > > Indirect addressing is a key feature in size-optimized code. That doesn't mean that LRA has to support it, btw, not necessarily; it may well be possible to do a good job of this in the later passes? Maybe postreload, maybe some peepholes, etc.? Segher
Re: Indirect memory addresses vs. lra
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool > wrote: > > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: >>> The old reload (reload[1].c) supports such addressing. As modern >>> mainstream architectures have no this kind of addressing, it was not >>> implemented in LRA. >> >> Is LRA only intended for "modern mainstream architectures"? > > I sure hope not! But it has only been *used* and *tested* much on such, > so far. Things are designed to work well for modern archs. > >> If yes, why is the old reload being deprecated? You can't have it both >> ways. Unless you want to obsolete all "not modern mainstream architectures" >> in GCC, it doesn't make sense to get rid of core functionality used by those >> architectures. >> >> Indirect addressing is a key feature in size-optimized code. > > That doesn't mean that LRA has to support it, btw, not necessarily; it > may well be possible to do a good job of this in the later passes? > Maybe postreload, maybe some peepholes, etc.? Possibly. But as Vladimir points out, indirect addressing affects register allocation (reducing register pressure). In older architectures that implement indirect addressing, that is one of the key ways in which the feature reduces code size. While I can see how peephole optimization can convert a address load plus a register indirect into a memory indirect instruction, does that help the register become available for other uses or is post-LRA too late for that? My impression is that it is too late, since at this point we're dealing with hard registers and making one free via peephole helps no one else. paul
Re: Indirect memory addresses vs. lra
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool > wrote: > > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: >>> The old reload (reload[1].c) supports such addressing. As modern >>> mainstream architectures have no this kind of addressing, it was not >>> implemented in LRA. >> >> Is LRA only intended for "modern mainstream architectures"? > > I sure hope not! But it has only been *used* and *tested* much on such, > so far. That's not entirely accurate. At the prodding of people pushing for the removal of CC0 and reload, I've added LRA support to pdp11 in the V9 cycle. And it works pretty well, in the sense of passing the compile tests. But I haven't yet examined the code quality vs. the old one in any detail. paul
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote: > On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote: > > > > > code does is cheap. With "x->is_a (PLUS)", who knows what is > > > > > happening > > > That's not my point -- my point was that it is *obvious* the way things > > > are now, which is nice. > > > > My reply is pointing out that it is just as (non-)obvious with or > > without that inline function, if you want to use any of the helper > > macros. > > But that is not what you suggested, or at least not how I read it. > x->is_a (PLUS) > is not obviously cheap or simple at all, while > GET_CODE (x) == PLUS > obviously *is*. > > The former also isn't readable. That's a matter of what style you prefer and it seems like no-one else shares my preference, and I accept that we're not going to make such a change. But there is really nothing more or less obvious about it. It's easy to go look at the code, as you probably once did when checking what GET_CODE or REG_P actually did, and is_a methods are expected to be lightweight. Regarding hiding things, consider that we just added LABEL_REF_P, which is for a comparison that happens less than half as often as PLUS in the codebase (and I think it was actually only used in one place). It was done presumably because the author/reviewers felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, even if the latter might be ever so slightly more transparent as to what its doing than the former. > > Indirection is *the* evil in programming. Some would say that "All problems in computer science can be solved by another level of indirection" ;)
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 01:12:33PM -0400, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote: > > Hi, > > > > On Wed, 7 Aug 2019, Arvind Sankar wrote: > > > > > => x->is_a (REG) > > > > Oh god, please no. Currently at least the RTL parts of GCC still have > > mostly a consistent and obvious style, which is a good thing. I have no > > idea why anyone would think the above is easier to read than REG_P (x). > > > > > > Ciao, > > Michael. > > P.S: Consider this: the current style served us quite well for the last 35 > > or so years, so before suggesting style changes, shouldn't you first work > > on the sources for some time? > > Well, the main point of the email was to ask for review of a patchset > that attempts to make progress on a TODO that has been outstanding for > at least 15 of those 35 years. Not everything that is in some TODO list somewhere is something generally agreed upon. Jakub
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 01:42:40PM -0400, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote: > But there is really nothing more or less obvious about it. That depends on what you are used to seeing, a lot. > It's easy to > go look at the code, as you probably once did when checking what > GET_CODE or REG_P actually did, It's in the documentation as well, and there are examples every tenth line of code to look at. > and is_a methods are expected to be > lightweight. Regarding hiding things, consider that we just added > LABEL_REF_P, which is for a comparison that happens less than half as > often as PLUS in the codebase (and I think it was actually only > used in one place). It was done presumably because the author/reviewers > felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, > even if the latter might be ever so slightly more transparent as to what > its doing than the former. LABEL_REF_P works out nicely because it is referring to something that is data, is not an operator. "Leaves" in an RTL expression, if you want to look at it that way. Predicates for other RTX codes aren't always as obvious, see CONST_P as example. PLUS_P would be a bit borderline. Part of the reason why REG_P and MEM_P and the like are nice, is that these predicates are often used in bigger conditions, maybe together with some XEXP and whatnot. Is that the case for PLUS_P? > > Indirection is *the* evil in programming. > > Some would say that "All problems in computer science can be solved by > another level of indirection" ;) Yes, and that is the problem. :-P Indirection doesn't solve problems, it just hides them. Diluting your code does not make it simpler, quite the opposite; it just makes it hard to spot the problem parts. Segher
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 08:14:01PM +0200, Jakub Jelinek wrote: > On Thu, Aug 08, 2019 at 01:12:33PM -0400, Arvind Sankar wrote: > > On Thu, Aug 08, 2019 at 03:04:53PM +, Michael Matz wrote: > > > Hi, > > > > > > On Wed, 7 Aug 2019, Arvind Sankar wrote: > > > > > > > => x->is_a (REG) > > > > > > Oh god, please no. Currently at least the RTL parts of GCC still have > > > mostly a consistent and obvious style, which is a good thing. I have no > > > idea why anyone would think the above is easier to read than REG_P (x). > > > > > > > > > Ciao, > > > Michael. > > > P.S: Consider this: the current style served us quite well for the last > > > 35 > > > or so years, so before suggesting style changes, shouldn't you first work > > > on the sources for some time? > > > > Well, the main point of the email was to ask for review of a patchset > > that attempts to make progress on a TODO that has been outstanding for > > at least 15 of those 35 years. > > Not everything that is in some TODO list somewhere is something generally > agreed upon. > > Jakub Surely there's general agreement on using REG_P etc? I don't see anyone objecting to it, and that's all the patchset does: to avoid any confusion the second half of the email asking about opinions on is_a is entirely independent from the first half describing the existing patchset.
Re: Expansion of narrowing math built-ins into power instructions
Hi. It took some time for me to finish with the folding part for fadd variants and till it is reviewed, I want to move ahead with power8/9 expansions on top of the current fadd patch. > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > which could be extended to allow DF inputs with an SF output; it doesn't > yet allow it. This might be very lousy but I am confused with the optabs and insn name rn, the comments in obtabs.def says that these patterns are present in md as insn names. How can fadd function be mapped with the "fadd3_fpr" pattern name? Also, faddl and daddl functions take long double as argument, can they also be expanded on DF to SF mode or only on QP float on power9? I have built GCC and applied my current patches on gcc112 and yes, on gcc135 too. Thanks, Tejas On Wed, 31 Jul 2019 at 20:17, Segher Boessenkool wrote: > > On Wed, Jul 31, 2019 at 12:23:18PM +0530, Tejas Joshi wrote: > > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > > > which could be extended to allow DF inputs with an SF output; it doesn't > > > yet allow it. > > > > Thanks for the inputs, I will try to address these points now. I have > > built GCC on gcc112 and will apply patch and test testcases there. > > For the QP float (binary128, KFmode, take your pick) you need Power9 or > newer, so gcc135. > > > Segher
Re: Indirect memory addresses vs. lra
On 2019-08-08 12:43 p.m., Paul Koning wrote: On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: On 2019-08-04 3:18 p.m., John Darrington wrote: I'm trying to write a back-end for an architecture (s12z - the ISA you can download from [1]). This arch accepts indirect memory addresses. That is to say, those of the form (mem (mem (...))) and although my TARGET_LEGITIMATE_ADDRESS function returns true for such addresses, LRA insists on reloading them out of existence. ... The old reload (reload[1].c) supports such addressing. As modern mainstream architectures have no this kind of addressing, it was not implemented in LRA. Is LRA only intended for "modern mainstream architectures"? No. As I wrote patches implementing indirect addressing is welcomed. It is hard to implement everything at once and by one person. If yes, why is the old reload being deprecated? You can't have it both ways. Unless you want to obsolete all "not modern mainstream architectures" in GCC, it doesn't make sense to get rid of core functionality used by those architectures. Indirect addressing is a key feature in size-optimized code.
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 02:35:27PM -0400, Arvind Sankar wrote: > Surely there's general agreement on using REG_P etc? I don't see anyone No objections from me for using REG_P and other *_P macros more. > objecting to it, and that's all the patchset does: to avoid any > confusion the second half of the email asking about opinions on is_a is > entirely independent from the first half describing the existing patchset. My comment was mainly targetted at the ->is_a stuff, but also a general comment that having something written in some wiki doesn't mean there is agreement on it. Jakub
Re: Use predicates for RTL objects
On Thu, Aug 08, 2019 at 01:26:42PM -0500, Segher Boessenkool wrote: > LABEL_REF_P works out nicely because it is referring to something that > is data, is not an operator. "Leaves" in an RTL expression, if you want > to look at it that way. > > Predicates for other RTX codes aren't always as obvious, see CONST_P as > example. PLUS_P would be a bit borderline. > > Part of the reason why REG_P and MEM_P and the like are nice, is that > these predicates are often used in bigger conditions, maybe together > with some XEXP and whatnot. Is that the case for PLUS_P? > Yes, it's used quite often in more complex conditions checking the operands (eg to see whether they're constants), or applied to XEXP's itself. But I'm in agreement that PLUS_P just seems odd somehow. The leaf/data vs operator distinction makes sense, maybe RTXOP_PLUS_P, but then you'd want that to check if it was being called on an operator, so I don't know if you'd do it unless/until we eventually have an rtx_op class and have done the other bits of converting to C++.
Re: Indirect memory addresses vs. lra
On Thu, Aug 08, 2019 at 01:25:27PM -0400, Paul Koning wrote: > > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool > > wrote: > > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: > >> Indirect addressing is a key feature in size-optimized code. > > > > That doesn't mean that LRA has to support it, btw, not necessarily; it > > may well be possible to do a good job of this in the later passes? > > Maybe postreload, maybe some peepholes, etc.? > > Possibly. But as Vladimir points out, indirect addressing affects > register allocation (reducing register pressure). Yeah, good point, esp. if you have only one or two registers that you can use for addressing at all. So it will have to happen during (or before?) RA, alright. Segher
Re: Indirect memory addresses vs. lra
On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote: > > > > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool > > wrote: > > > > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: > >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: > >>> The old reload (reload[1].c) supports such addressing. As modern > >>> mainstream architectures have no this kind of addressing, it was not > >>> implemented in LRA. > >> > >> Is LRA only intended for "modern mainstream architectures"? > > > > I sure hope not! But it has only been *used* and *tested* much on such, > > so far. > > That's not entirely accurate. At the prodding of people pushing for > the removal of CC0 and reload, I've added LRA support to pdp11 in the > V9 cycle. I said "much" :-) Pretty much all design input so far has been from "modern mainstream architectures", as far as I can make out. Now one of those has the most "interesting" (for RA) features that many less mainstream archs have (a not-so-very-flat register file), so it should still work pretty well hopefully. > And it works pretty well, in the sense of passing the > compile tests. But I haven't yet examined the code quality vs. the > old one in any detail. That would be quite interesting to see, also for the other ports that still need conversion: how much (if any) degradation should you expect from a straight-up conversion of a port to LRA, without any retuning? Segher
Re: Indirect memory addresses vs. lra
On 8/8/19 1:19 PM, Segher Boessenkool wrote: > On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote: >> >> >>> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool >>> wrote: >>> >>> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: > On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: > The old reload (reload[1].c) supports such addressing. As modern > mainstream architectures have no this kind of addressing, it was not > implemented in LRA. Is LRA only intended for "modern mainstream architectures"? >>> >>> I sure hope not! But it has only been *used* and *tested* much on such, >>> so far. >> >> That's not entirely accurate. At the prodding of people pushing for >> the removal of CC0 and reload, I've added LRA support to pdp11 in the >> V9 cycle. > > I said "much" :-) > > Pretty much all design input so far has been from "modern mainstream > architectures", as far as I can make out. Now one of those has the > most "interesting" (for RA) features that many less mainstream archs > have (a not-so-very-flat register file), so it should still work pretty > well hopefully. Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to date. So I'm not surprised it's not working. My suggestion would be to ignore the double-indirect aspect of the architecture right now, get the port working, then come back and try to make double-indirect addressing modes work. > >> And it works pretty well, in the sense of passing the >> compile tests. But I haven't yet examined the code quality vs. the >> old one in any detail. > > That would be quite interesting to see, also for the other ports that > still need conversion: how much (if any) degradation should you expect > from a straight-up conversion of a port to LRA, without any retuning? I did the v850 last year where it was a wash or perhaps a slight improvement for codesize, which is a reasonable approximation for performance on that target. I was working a bit on converting the H8 away from cc0 with an eye towards LRA as well. Given how registers overlap on the H8, the most straightforward port should end up with properties much like 32bit x86. I suspect the independent addressing of the high/low register parts might be better handled by LRA, but I wasn't going to do anything beyond the "just make it work". jeff
Re: Expansion of narrowing math built-ins into power instructions
Hi! On Fri, Aug 09, 2019 at 12:14:54AM +0530, Tejas Joshi wrote: > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns, > > which could be extended to allow DF inputs with an SF output; it doesn't > > yet allow it. > > This might be very lousy but I am confused with the optabs and insn > name rn, the comments in obtabs.def says that these patterns are > present in md as insn names. How can fadd function be mapped with the > "fadd3_fpr" pattern name? The actual name starts with an asterisk, which means as it is it can never be used by name. But, right above this pattern, there is the define_expand named add3 (for modes SFDF). These current patterns all take the same mode for all inputs and outputs (that's what 3 indicates, say, fadddf3). You will need to define something that takes two SFs in and produces a DF. That cannot really be in this same pattern, it needs a float_extend added (you can do all kinds of trickery, but just adding a few extra patterns is much easier than define_subst and whatnot). > Also, faddl and daddl functions take long double as argument, can they > also be expanded on DF to SF mode or only on QP float on power9? We can have three different long double modes on powerpc: DP float, QP float, or "IBM long double", also known as "double double", which is essentially the sum of two double precision numbers. Types (a source level construct) are not the same as modes (an RTL concept). Segher
Re: Use predicates for RTL objects
On 8/8/19 11:06 AM, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 08:31:28AM -0600, Jeff Law wrote: >> True, but they could be. When David was working in this space a few >> years ago I concluded that the main value in sub-classing the various >> RTL operators just wansn't worth the effort. Instead we focused on >> starting to tear apart things like the toplevel objects into rtx_insn >> and the like. THere's little value in treating those as simple RTXs. >> INSN_LIST and the like were also ripe for this treatment. >> >> The biggest value in making a real class for the operators things would >> be to move the runtime RTL checking into a compile-time check. But I >> couldn't really green light something like that without first completing >> the rtx_insn changes. > > Are there any notes or old discussion threads on what remains? I would > be interested in taking a look if no-one else is. I don't recall if that discussion was internal or external. If the latter, then it'd be in the gcc-patches archives. Jeff
Re: Use predicates for RTL objects
On 8/8/19 11:42 AM, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote: >> On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote: >> code does is cheap. With "x->is_a (PLUS)", who knows what is happening That's not my point -- my point was that it is *obvious* the way things are now, which is nice. >>> >>> My reply is pointing out that it is just as (non-)obvious with or >>> without that inline function, if you want to use any of the helper >>> macros. >> >> But that is not what you suggested, or at least not how I read it. >> x->is_a (PLUS) >> is not obviously cheap or simple at all, while >> GET_CODE (x) == PLUS >> obviously *is*. >> >> The former also isn't readable. > > That's a matter of what style you prefer and it seems like no-one else > shares my preference, and I accept that we're not going to make such a > change. > > But there is really nothing more or less obvious about it. It's easy to > go look at the code, as you probably once did when checking what > GET_CODE or REG_P actually did, and is_a methods are expected to be > lightweight. Regarding hiding things, consider that we just added > LABEL_REF_P, which is for a comparison that happens less than half as > often as PLUS in the codebase (and I think it was actually only > used in one place). It was done presumably because the author/reviewers > felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, > even if the latter might be ever so slightly more transparent as to what > its doing than the former. I think what Segher is referring to is that GCC developers should know that GET_CODE is just x->code, ie, a single dereference, similarly for other RTL/TREE accessors. A function call (or something that looks like a function call) has traditionally been reserved for things that are less performance sensitive and could be doing more work within GCC. But those are merely conventions and ones that we've had in this project for 30+ years and are to some degree driven by the C language as it stood in the 80s. We're not as strict about those conventions as we've been in the past, but I don't think we're ready to throw them totally out the window. There's nothing *inherently* cheaper about either form. Both could be used in either way. Jeff
Re: Use predicates for RTL objects
On 8/8/19 12:46 PM, Jakub Jelinek wrote: > On Thu, Aug 08, 2019 at 02:35:27PM -0400, Arvind Sankar wrote: >> Surely there's general agreement on using REG_P etc? I don't see anyone > > No objections from me for using REG_P and other *_P macros more. Right. These are convenience macros and I think they're generally a good thing. Other good examples would be things like POINTER_TYPE_P which accepts POINTER_TYPE or REFERENCE type -- it's way to easy to do something like TREE_TYPE (x) == POINTER_TYPE and thus miss handling reference types. > >> objecting to it, and that's all the patchset does: to avoid any >> confusion the second half of the email asking about opinions on is_a is >> entirely independent from the first half describing the existing patchset. > > My comment was mainly targetted at the ->is_a stuff, but also a general > comment that having something written in some wiki doesn't mean there is > agreement on it. Agreed on both points. jeff
gcc-7-20190808 is now available
Snapshot gcc-7-20190808 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190808/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 274220 You'll find: gcc-7-20190808.tar.xzComplete GCC SHA256=c9f13f2ec51ef8419a6a70fceb090602b8c39ab951a6b43f1a63984398b47024 SHA1=80791c4a40d73e9fde1a53e3c3a1bb28d5a128d7 Diffs from 7-20190801 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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: Expansion of narrowing math built-ins into power instructions
On Thu, 8 Aug 2019, Segher Boessenkool wrote: > These current patterns all take the same mode for all inputs and outputs > (that's what 3 indicates, say, fadddf3). You will need to define > something that takes two SFs in and produces a DF. That cannot really For example, md.texi describes standard patterns such as mulhisi3 that multiply two HImode values and produce an SImode result (widening integer multiply). Using a similar naming pattern, you might have a pattern adddfsf3 that multiplies two DFmode values and produces an SFmode result (or you could call it something like add_truncdfsf3 if you wish to emphasise the truncation involved, for example). Similarly addtfsf3 that multiplies TFmode and produces an SFmode result, and so on. Of course these names need documenting (and you need corresponding RTL for them to generate that distinguishes the fused add+truncate from the different RTL for separate addition and truncation with double rounding). In cases where long double and double have the same mode, the daddl function should use the existing adddf3 pattern. -- Joseph S. Myers jos...@codesourcery.com
