On 09/05/12 11:53, paul_kon...@dell.com wrote:
He was showing the RTL expansion of the example he gave:
Ah, right. I interpreted it as if it was what the movmem expanded to.
--
PMatos
On May 9, 2012, at 5:34 AM, Paulo J. Matos wrote:
> On 08/05/12 21:57, Jan Hubicka wrote:
>>
>> In expanded form it is
>>
>> (set (reg5) (const 10))
>>
>> (parallel [(set (reg2) (const 0))
>>(set (reg0) (plus (reg3) (reg5)))
>>(set (reg1) (plus (reg4) (reg5)))
>>
On 08/05/12 21:57, Jan Hubicka wrote:
In expanded form it is
(set (reg5) (const 10))
(parallel [(set (reg2) (const 0))
(set (reg0) (plus (reg3) (reg5)))
(set (reg1) (plus (reg4) (reg5)))
(set (mem (reg3)) (mem (reg4)))])
(set (reg0) (plus (reg0) (cons
Jan Hubicka writes:
>> Jan Hubicka writes:
>>
>> >>
>> >> I can accept the issue as a matter of documentation, but I don't
>> >> understand the rest. Remember that all the patterns are executed in
>> >> parallel. I don't see how adding a USE in parallel could affect
>> >> anything about how
> Jan Hubicka writes:
>
> >>
> >> I can accept the issue as a matter of documentation, but I don't
> >> understand the rest. Remember that all the patterns are executed in
> >> parallel. I don't see how adding a USE in parallel could affect
> >> anything about how the operand is used.
> >
> >>
Jan Hubicka writes:
>>
>> I can accept the issue as a matter of documentation, but I don't
>> understand the rest. Remember that all the patterns are executed in
>> parallel. I don't see how adding a USE in parallel could affect
>> anything about how the operand is used.
>
>> >> >> (define_ins
>
> I can accept the issue as a matter of documentation, but I don't
> understand the rest. Remember that all the patterns are executed in
> parallel. I don't see how adding a USE in parallel could affect
> anything about how the operand is used.
> >> >> (define_insn "*rep_movqi"
> >> >>[(s
Jan Hubicka writes:
>> "Paulo J. Matos" writes:
>>
>> > On 04/05/12 19:48, Ian Lance Taylor wrote:
>> >
>> >> The i386 rep_movqi insn is an example:
>> >>
>> >> (define_insn "*rep_movqi"
>> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
>> >> (set (match_operand:P 0
> "Paulo J. Matos" writes:
>
> > On 04/05/12 19:48, Ian Lance Taylor wrote:
> >
> >> The i386 rep_movqi insn is an example:
> >>
> >> (define_insn "*rep_movqi"
> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
> >> (set (match_operand:P 0 "register_operand" "=D")
> >>
"Paulo J. Matos" writes:
> On 04/05/12 19:48, Ian Lance Taylor wrote:
>
>> The i386 rep_movqi insn is an example:
>>
>> (define_insn "*rep_movqi"
>>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
>> (set (match_operand:P 0 "register_operand" "=D")
>> (plus:P (mat
On 04/05/12 19:48, Ian Lance Taylor wrote:
The i386 rep_movqi insn is an example:
(define_insn "*rep_movqi"
[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
(set (match_operand:P 0 "register_operand" "=D")
(plus:P (match_operand:P 3 "register_operand" "0")
writes:
> What I was trying to describe is the handling of a memcpy operation in the
> .md file, where the operands are the memory pointers and (in my case) I want
> to tell the machinery that the registers it's using to pass in the addresses
> no longer have those addresses in them on complet
On May 4, 2012, at 1:52 PM, Ian Lance Taylor wrote:
> writes:
>
>> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
>>
>>> writes:
>>>
I thought that the "operand" in a mem:BLK is the pointer to the block,
not the block itself. So if the instruction(s) generated don't touch
>>
writes:
> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
>
>> writes:
>>
>>> I thought that the "operand" in a mem:BLK is the pointer to the block,
>>> not the block itself. So if the instruction(s) generated don't touch
>>> the pointer -- a likely answer for a block-move instruction --
On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
> writes:
>
>> I thought that the "operand" in a mem:BLK is the pointer to the block,
>> not the block itself. So if the instruction(s) generated don't touch
>> the pointer -- a likely answer for a block-move instruction -- then
>> the opera
writes:
> I thought that the "operand" in a mem:BLK is the pointer to the block,
> not the block itself. So if the instruction(s) generated don't touch
> the pointer -- a likely answer for a block-move instruction -- then
> the operand would be read-only. Is that the right interpretation?
Yes.
On May 4, 2012, at 9:44 AM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> Expand generates:
>>
>> (define_insn_and_split "movmem_long"
>> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>> (set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
>>(m
On 04/05/12 14:44, Ian Lance Taylor wrote:
I agree that there is something wrong here. I agree that as written
the constraints for operands 0, 1, and 2 should have a '+'.
That said, a '+' constraint is most useful for a pattern that expands
into multiple instructions. I think this would be bet
"Paulo J. Matos" writes:
> Expand generates:
>
> (define_insn_and_split "movmem_long"
> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>(set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
> (mem:BLK (match_operand:QI 1 "register_operand" "x,c")))
>(s
Hi,
I was just trying to understand exactly what constraint modifiers + and
= mean. I have read the manual but I am uncertain about their meaning in
the context of the following rule (without any modifiers):
Expand generates:
(define_insn_and_split "movmem_long"
[(set (match_operand:QI 2 "
20 matches
Mail list logo
