> On 16 Sep 2017, at 8:59 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Sat, Sep 16, 2017 at 08:47:03AM +1200, Michael Clark wrote:
>> RISC-V defines promote_mode on RV64 to promote SImode to signed DImode
>> subregisters. I did an experiment on RISC-V to not promote SImode to DImode
>> an
Hi!
On Sat, Sep 16, 2017 at 08:47:03AM +1200, Michael Clark wrote:
> RISC-V defines promote_mode on RV64 to promote SImode to signed DImode
> subregisters. I did an experiment on RISC-V to not promote SImode to DImode
> and it improved codegen for many of my regression test cases, but
> unfort
> On 16 Sep 2017, at 1:04 AM, David Edelsohn wrote:
>
> On Tue, Sep 5, 2017 at 5:26 AM, Prathamesh Kulkarni
> wrote:
>> Hi,
>> I have attached revamped version of Kugan's original patch for type promotion
>> (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00472.html)
>> rebased on r249469. The m
On Fri, 15 Sep 2017, Richard Biener wrote:
> IIRC the last time we went over this patch I concluded a better first
> step would be to expose call ABI details on GIMPLE much earlier. But I
> may misremember here.
Some call details are exposed in the front ends (see
targetm.calls.promote_prototy
On September 15, 2017 6:56:04 PM GMT+02:00, Jeff Law wrote:
>On 09/15/2017 10:19 AM, Segher Boessenkool wrote:
>> On Fri, Sep 15, 2017 at 09:18:23AM -0600, Jeff Law wrote:
>>> WORD_REGISTER_OPERATIONS works with PROMOTE_MODE. The reason you
>can't
>>> define WORD_REGISTER_OPERATIONS on aarch64 is
On Fri, Sep 15, 2017 at 02:06:22PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 08:40:41PM +0200, Jakub Jelinek wrote:
> > > > I'm greatly oversimplifying here. Type promotion/demotion is fairly
> > > > complex to get right.
> > >
> > > Yeah :-(
> > >
> > > Maybe the best thing is
On Fri, Sep 15, 2017 at 08:40:41PM +0200, Jakub Jelinek wrote:
> > > I'm greatly oversimplifying here. Type promotion/demotion is fairly
> > > complex to get right.
> >
> > Yeah :-(
> >
> > Maybe the best thing is to promote really early, but to keep track of which
> > bits matter. And then adj
On Fri, Sep 15, 2017 at 12:13:39PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 10:56:04AM -0600, Jeff Law wrote:
> > Yes, these are some of the things we kicked around. One of the most
> > interesting conclusions was that for these target issues we'd really
> > like a target.pd file
I am pleased to announce that the GCC Steering Committee has
appointed Pierre-Marie de Rodat as Ada co-maintainer.
Please join me in congratulating Pierre-Marie on his new role.
P-M, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Fri, Sep 15, 2017 at 10:56:04AM -0600, Jeff Law wrote:
> Yes, these are some of the things we kicked around. One of the most
> interesting conclusions was that for these target issues we'd really
> like a target.pd file to handle this class of transformations just prior
> to rtl expansion.
But
On 09/15/2017 10:19 AM, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 09:18:23AM -0600, Jeff Law wrote:
>> WORD_REGISTER_OPERATIONS works with PROMOTE_MODE. The reason you can't
>> define WORD_REGISTER_OPERATIONS on aarch64 is because that the implicit
>> promotion is sometimes to 32 bits an
On Fri, Sep 15, 2017 at 09:18:23AM -0600, Jeff Law wrote:
> WORD_REGISTER_OPERATIONS works with PROMOTE_MODE. The reason you can't
> define WORD_REGISTER_OPERATIONS on aarch64 is because that the implicit
> promotion is sometimes to 32 bits and sometimes to 64 bits.
> WORD_REGISTER_OPERATIONS can'
On 09/15/2017 07:47 AM, Wilco Dijkstra wrote:
> David Edelsohn wrote:
>
>> Why does AArch64 define PROMOTE_MODE as SImode? GCC ports for other
>> RISC targets mostly seem to use a 64-bit mode. Maybe SImode is the
>> correct definition based on the current GCC optimization
>> infrastructure, but
David Edelsohn wrote:
> Why does AArch64 define PROMOTE_MODE as SImode? GCC ports for other
> RISC targets mostly seem to use a 64-bit mode. Maybe SImode is the
> correct definition based on the current GCC optimization
> infrastructure, but this seems like a change that should be applied to
> a
On Tue, Sep 5, 2017 at 5:26 AM, Prathamesh Kulkarni
wrote:
> Hi,
> I have attached revamped version of Kugan's original patch for type promotion
> (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00472.html)
> rebased on r249469. The motivation of the pass is to minimize
> generation of subregs
> to
Hi Prathamesh,
I've tried out the latest version and it works really well. It built and ran
SPEC2017 without any issues or regressions (I didn't do a detailed comparison
which would mean multiple runs, however a single run showed performance is
pretty much the same on INT and 0.1% faster on FP)
> handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it
> will not issue a warning for C++ even though the pragma is effectively
> ignored.
Indeed, unlike for the attribute, will fix, thanks.
--
Eric Botcazou
* Eric Botcazou:
>> By the way, what happened to the C++ bits? I think the c-family patch
>> which went in assumes that the C++ bits are there as well.
>
> I don't really understand what you mean by "assume" here,
handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it
will not is
On Fri, Sep 15, 2017 at 12:07 AM, Jeff Law wrote:
> On 09/14/2017 01:28 PM, Niels Möller wrote:
>> This is more of a question than a bug report, so I'm trying to send it
>> to the list rather than filing a bugzilla issue.
>>
>> I think it's quite common to write for- and while-loops where the
>> c
> By the way, what happened to the C++ bits? I think the c-family patch
> which went in assumes that the C++ bits are there as well.
I don't really understand what you mean by "assume" here, but the C++ bits
were incomplete and never got reviewed; I can resurrect them if there is some
interest
* Eric Botcazou:
>> To support applications that assume big-endian memory layout on little-
>> endian systems, I'm considering adding support for reversing the
>> storage order to GCC.
>
> That was also the goal of the scalar_storage_order attribute.
By the way, what happened to the C++ bits? I
21 matches
Mail list logo
