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 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.
>
> Als
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
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 includ
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 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.
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 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
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 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 appro
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
> 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
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 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 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
> 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
> 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
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 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 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 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)
>
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 wi
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.
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 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 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
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) sup
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
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 i
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 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 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
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
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 stan
34 matches
Mail list logo
