On Wed, Aug 7, 2019 at 7:34 PM 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_cod
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
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 th
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. Inst
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 obvi
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 o
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)
>
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 probab
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
> >
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 th
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
> id
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 thi
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 call
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
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,
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 (no
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
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
On Wed, Aug 07, 2019 at 01:05:51PM -0500, 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
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 mo
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 r
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
Hi,
I have posted a patch series [1] for converting some of the RTL code to
use predicate macros, as described in the suggestions for beginner GCC
projects [2]. Segher was kind enough to give some comments on the
initial posting [3].
The code has been bootstrapped natively on x86_64, and I have bu
> Do people still want (GET_CODE (rtx) == XXX) cleaned up to XXX_P(RTX).
I would think so -- did you get that from the beginner's project list?
> I would probably do all the plus/minus stuff first. Submit that as a patch.
Sure. Please read the patch submission guidelines before starting.
> ps.
Do people still want (GET_CODE (rtx) == XXX) cleaned up to XXX_P(RTX).
If so I notice that there are quite a few of the following:
200 of
GET_CODE(rtx) == PLUS ---> PLUS_P(rtx)
50 of
GET_CODE(rtx) == MINUS > MINUS_P(rtx)
550 of
GET_CODE(rtx) == CONST_INT ---> CONST_INT_P(rtx)
70 of
GET_CO
25 matches
Mail list logo
