On Tue, Sep 19, 2017 at 4:58 PM, Jeff Law wrote:
> On 09/19/2017 05:40 AM, Richard Biener wrote:
>
>>> We might also need some way of having gimple statements that can
>>> convert (or promote to the type without extensions) just to keep the
>>> gimple type system happy.
>>
>> Yes, one of the "issu
On Tue, 2017-09-19 at 11:13 +1000, Kugan Vivekanandarajah wrote:
> > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00929.html
> I tried the testases you have in the patch with type promotion. Looks
> like forwprop is reversing the promotion there. I haven't looked in
> detail yet but -fno-tree-for
On Tue, Sep 19, 2017 at 01:40:02PM +0200, Richard Biener wrote:
> > I think this would be very useful. Some of the regressions in type
> > promotion comes from parameters/return values. ABI in some cases
> > guarantees that they are properly extended but during type promotion
> > we promote (or ext
On 09/19/2017 05:40 AM, Richard Biener wrote:
>> We might also need some way of having gimple statements that can
>> convert (or promote to the type without extensions) just to keep the
>> gimple type system happy.
>
> Yes, one of the "issues" is GIMPLE doesn't have subregs (I think that's
> a go
On Mon, Sep 18, 2017 at 4:30 AM, Kugan Vivekanandarajah
wrote:
> Hi Richard,
>
> On 16 September 2017 at 06:12, Richard Biener
> wrote:
>> 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 -060
Hi Steve,
On 19 September 2017 at 05:45, Steve Ellcey wrote:
> On Mon, 2017-09-18 at 23:29 +0530, Prathamesh Kulkarni wrote:
>>
>> Hi Steve,
>> The patch is currently based on r249469. I will rebase it on ToT and
>> look into the build failure.
>> Thanks for pointing it out.
>>
>> Regards,
>> Pra
On Mon, 2017-09-18 at 23:29 +0530, Prathamesh Kulkarni wrote:
>
> Hi Steve,
> The patch is currently based on r249469. I will rebase it on ToT and
> look into the build failure.
> Thanks for pointing it out.
>
> Regards,
> Prathamesh
OK, I applied it to that version successfully. The thing I wa
On 18 September 2017 at 23:12, Steve Ellcey wrote:
> On Fri, 2017-09-15 at 12:22 +, Wilco Dijkstra wrote:
>
> Wilco or Prathamesh,
>
> I could not apply this patch (cleanly) to ToT. match.pd did not apply,
> I think I fixed that. The cfgexpand.c patch applied but will not
> build. I get thi
On Fri, 2017-09-15 at 12:22 +, Wilco Dijkstra wrote:
Wilco or Prathamesh,
I could not apply this patch (cleanly) to ToT. match.pd did not apply,
I think I fixed that. The cfgexpand.c patch applied but will not
build. I get this error:
../../../src/gcc/gcc/cfgexpand.c: In function ‘rtx_def
Hi Richard,
On 16 September 2017 at 06:12, Richard Biener
wrote:
> 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.
> 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
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)
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 avoid redundant zero/sign extensions by carrying out computations
in PR
26 matches
Mail list logo
