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
> deta
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
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
;>>> @end defmac
>>>> """
>>>>
>>>> Exactly what operations? For almost all targets it isn't true for
>>>*all*
>>>> operations. Or no targets even, if you include rotate, etc.
>>>>
>>>> For tar
issue of having GCC recognize that ldrb/ldhb zero out the top of a
> register and thus we do not need to mask it out later.
>
> 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 t
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
er than a word are always performed on the entire register.
>>> Most RISC machines have this property and most CISC machines do not.
>>> @end defmac
>>> """
>>>
>>> Exactly what operations? For almost all targets it isn't true for
&g
> 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/msg004
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
>> @end defmac
>> """
>>
>> Exactly what operations? For almost all targets it isn't true for
>*all*
>> operations. Or no targets even, if you include rotate, etc.
>>
>> For targets that have both 32-bit and 64-bit operations it 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.
> > >
> >
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
> > like a target.pd file to handle this class of transformations just prior
> > to rtl expansion.
>
> But often combine will need to know about which bits you actually care
> about (and other passes too, but combine is the biggie).
>
> > Essentially early type promotio
to rtl expansion.
But often combine will need to know about which bits you actually care
about (and other passes too, but combine is the biggie).
> Essentially early type promotion/demotion would be concerned with cases
> where we can eliminate operations in a target independent manner and
>
> operations. Or no targets even, if you include rotate, etc.
>
> For targets that have both 32-bit and 64-bit operations it is never true
> either.
>
>> And I'm also keen on doing something with type promotion -- Kai did some
>> work in this space year
7;s work -- with the caveat that if it
> stumbles across the same issues as Kai's work that it likely wouldn't be
> acceptable in its current form.
Doing type promotion too aggressively reduces code quality. "Just" find
a sweet spot :-)
Example: on Power, an AND of QImo
ch will eliminate a large number of zero
extensions.
I also think improving REE would help -- in particular having it handle
subregs which are just another way of expressing an extension. I
suspect that would also allow folding away a goodly amount of extensions.
And I'm also keen on doing somethi
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
> g
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 computatio
Sorry for the late answer.
Umesh Kalappa writes:
> Was porting gcc 4.8.1 to the private target which has 8 bit regs and
> can be used as pair for 16bit like AB ,CD but not BC or AD.
>
> I was stuck in the type promotion like
>
> int i;
> unsigned char c;
>
&g
Hi All,
Was porting gcc 4.8.1 to the private target which has 8 bit regs and
can be used as pair for 16bit like AB ,CD but not BC or AD.
I was stuck in the type promotion like
int i;
unsigned char c;
int test ()
{
i =c;
}
defined the zero_extendqihi2 pattern for the above c construct
On Fri, 27 Feb 2009, Sean D'Epagnier wrote:
> Hi,
>
> I just added support for printf and scanf of fixed point types to avr
> libc. I wanted to handle:
>
> Currently "accum" and "fract" work, but not "short accum" or "short fract"
>
> This is not a problem for integers currently since they g
Hi,
I just added support for printf and scanf of fixed point types to avr
libc. I wanted to handle:
Currently "accum" and "fract" work, but not "short accum" or "short fract"
This is not a problem for integers currently since they get type
promoted when passed with stdarg.
There is nothing i
On 12/4/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8 m
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each 8x
32 matches
Mail list logo
