Richard Sandiford <[EMAIL PROTECTED]> writes:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
>> Richard Sandiford wrote:
>>> Also, you need to beware of cases in which operands[1] overlaps
>>> operands[0]. The splitter says:
>>>
>>> [(set (match_dup 2) (match_dup 4))
>>> (set (match_dup 3) (match_
"Omar Torres" <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> Also, you need to beware of cases in which operands[1] overlaps
>> operands[0]. The splitter says:
>>
>> [(set (match_dup 2) (match_dup 4))
>> (set (match_dup 3) (match_dup 5))]
>>
>> and operands[2] is always the highpart:
On Tue, May 20, 2008 at 2:47 PM, Paul Brook <[EMAIL PROTECTED]> wrote:
> Does this work reliably for straight mov patterns and during reload? Sounds
> like in the general case it would need secondary reloads, which is a whole
> lot of extra magic.
Hmm, right. Maybe something like what rs6000 does
On Tuesday 20 May 2008, Andrew Pinski wrote:
> On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> > By looking at other ports, I learned that I can detect when this happens
> > by using the reg_overlap_mentioned_p(). Here is one case:
> > (insn 43 115 74 (set (reg:HI 7 %i0h)
On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> By looking at other ports, I learned that I can detect when this happens
> by using the reg_overlap_mentioned_p(). Here is one case:
> (insn 43 115 74 (set (reg:HI 7 %i0h)
> (mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig
Richard Sandiford wrote:
> Also, you need to beware of cases in which operands[1] overlaps
> operands[0]. The splitter says:
>
> [(set (match_dup 2) (match_dup 4))
> (set (match_dup 3) (match_dup 5))]
>
> and operands[2] is always the highpart:
>
>operands[2] = gen_highpart(QImode, operands
Richard Sandiford wrote:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
> More importantly:
>
>>operands[4] = simplify_gen_subreg(QImode,operands[1],HImode,0);
>>operands[5] = simplify_gen_subreg(QImode,operands[1],HImode,1);
>
> ..this code is designed to handle REGs and CONST_INTs co
Richard Sandiford wrote:
>
> You might as well make the first operand a register_operand and
> avoid the REG_P check.
I agree. I implemented this change and it works as expected.
>More importantly:
>
>>operands[4] = simplify_gen_subreg(QImode,operands[1],HImode,0);
>>operands[5]
Just a few suggestions for simplfying this...
"Omar Torres" <[EMAIL PROTECTED]> writes:
> (define_split
>[(set (match_operand:HI 0 "nonimmediate_operand" "")
> (match_operand:HI 1 "general_operand" ""))]
>"reload_completed
> && REG_P (operands[0])"
You might as well make
> Any suggestions on how to fix this issue?
gen_int_mode
--
Eric Botcazou
Just correcting a typo...
Omar Torres wrote:
> I split it into:
(set (reg:QI 1 %r3)
(const_int 127 [0x7f])
(set (reg:QI 2 %r2)
(const_int 255 [0xFF])
Hi All,
Since the architecture I am working with only support byte size moves,
I created a define_split break HI-move insn's into two QI-moves.
For example, the following insn:
(insn 84 5 9 (set (reg:HI 1 %r3)
(const_int 32767 [0x7fff])) 3 {*movhi} (nil)
(nil))
I split it into:
(
12 matches
Mail list logo
