>> Now, in order to get rid of the subregs in the pattern combine creates,
>> I would need to be able to do something like
>>
>> (define_subst "subreg_subst"
>> [(set (match_operand:DI 0 "" "")
>> (shift:DI (match_operand:DI 1 "" "")
>>(subreg:SI (match_dup:DI 2)))]
>>
>>
On 5/15/19 8:30 AM, Robin Dapp wrote:
>> It would really help if you could provide testcases which show the
>> suboptimal code and any analysis you've done.
>
> I tried introducing a define_subst pattern that substitutes something
> one of two other subst patterns already changed.
>
> The first s
> It would really help if you could provide testcases which show the
> suboptimal code and any analysis you've done.
I tried introducing a define_subst pattern that substitutes something
one of two other subst patterns already changed.
The first subst pattern helps remove a superfluous and on the
On Mon, May 13, 2019 at 8:29 PM Jeff Law wrote:
>
> On 5/13/19 1:32 AM, Richard Sandiford wrote:
> >
> > IMO we should only consider deprecating the macro. I'm not sure how
> > much practical effect that will have though. cc0 was deprecated ages
> > ago but we're a still a long way from getting
On 5/13/19 1:32 AM, Richard Sandiford wrote:
>
> IMO we should only consider deprecating the macro. I'm not sure how
> much practical effect that will have though. cc0 was deprecated ages
> ago but we're a still a long way from getting rid of it. :-)
Yea, but (in theory) removing SHIFT_COUNT_TRU
Robin Dapp writes:
>>> Bit tests on x86 also truncate [1], if the bit base operand specifies
>>> a register, and we don't use BT with a memory location as a bit base.
>>> I don't know what is referred with "(real or pretended) bit field
>>> operations" in the documentation for SHIFT_COUNT_TRUNCATE
On Fri, May 10, 2019 at 4:35 PM Segher Boessenkool
wrote:
>
> On Fri, May 10, 2019 at 09:42:47AM +0200, Richard Biener wrote:
> > On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
> > > > But IL semantic differences based on mode is even worse. What happens
> > > > if STV then substitues a vect
On Fri, May 10, 2019 at 09:42:47AM +0200, Richard Biener wrote:
> On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
> > > But IL semantic differences based on mode is even worse. What happens
> > > if STV then substitues a vector register/op but you previously optimized
> > > with the assumption
On 5/10/19 1:08 AM, Richard Biener wrote:
> On Thu, May 9, 2019 at 6:00 PM Jeff Law wrote:
>>
>> On 5/9/19 5:52 AM, Robin Dapp wrote:
>>> Hi,
>>>
>>> while trying to improve s390 code generation for rotate and shift I
>>> noticed superfluous subregs for shift count operands. In our backend we
>>>
Hi,
> Would a shift_truncation_mask (rtx op, machine_mode mode) as replacement
> for SHIFT_COUNT_TRUNCATED and the old hook make more sense than just
> relying on the mode? That would be a way to alleviate the first counter
> argument to SHIFT_COUNT_TRUNCATED ("not flexible enough").
Well I thin
>> Bit tests on x86 also truncate [1], if the bit base operand specifies
>> a register, and we don't use BT with a memory location as a bit base.
>> I don't know what is referred with "(real or pretended) bit field
>> operations" in the documentation for SHIFT_COUNT_TRUNCATED:
>>
>> However, o
On Fri, May 10, 2019 at 9:42 AM Richard Biener
wrote:
>
> On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
> >
> > On Fri, May 10, 2019 at 9:10 AM Richard Biener
> > wrote:
> > >
> > > On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
> > > >
> > > > >> Event SHIFT_COUNT_TRUNCATED is no per
On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
>
> On Fri, May 10, 2019 at 9:10 AM Richard Biener
> wrote:
> >
> > On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
> > >
> > > >> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
> > > >> does because we always only cons
On Fri, May 10, 2019 at 9:10 AM Richard Biener
wrote:
>
> On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
> >
> > >> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
> > >> does because we always only consider the last 6 bits of a shift operand.>
> > >> Despite all the war
On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
>
> >> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
> >> does because we always only consider the last 6 bits of a shift operand.>
> >> Despite all the warnings in the other backends, most notably
> >> SHIFT_COUNT_TRUNCATE
On Thu, May 9, 2019 at 6:00 PM Jeff Law wrote:
>
> On 5/9/19 5:52 AM, Robin Dapp wrote:
> > Hi,
> >
> > while trying to improve s390 code generation for rotate and shift I
> > noticed superfluous subregs for shift count operands. In our backend we
> > already have quite cumbersome patterns that wo
>> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
>> does because we always only consider the last 6 bits of a shift operand.>
>> Despite all the warnings in the other backends, most notably
>> SHIFT_COUNT_TRUNCATED being "discouraged" as mentioned in riscv.h, I
>> wrote the a
On Thu, May 09, 2019 at 09:59:55AM -0600, Jeff Law wrote:
> THe main reason it's discouraged is because some targets have insns
> where the count would be truncated and others where it would not. So
> for example normal shifts might truncate, but vector shifts might or
> (mips) or shifts might tr
[ Please Cc: me on combine patches. Thanks! ]
On Thu, May 09, 2019 at 01:52:58PM +0200, Robin Dapp wrote:
> I had already finished all the patterns when I realized that
> SHIFT_COUNT_TRUNCATED and the target hook shift_truncation_mask already
> exist and could do what is needed without extra patt
On 5/9/19 5:52 AM, Robin Dapp wrote:
> Hi,
>
> while trying to improve s390 code generation for rotate and shift I
> noticed superfluous subregs for shift count operands. In our backend we
> already have quite cumbersome patterns that would need to be duplicated
> (or complicated further by more s
20 matches
Mail list logo
