On 07/19/2011 08:57 AM, Paulo J. Matos wrote:
> On 19/07/11 16:41, Richard Henderson wrote:
>> (or fails to set the flags in a way that
>> is useful for the comparison).
>
> I am not sure I understand the above. Could you give an example where
> certain flags might be set but are not useful for co
On 19/07/11 16:41, Richard Henderson wrote:
(or fails to set the flags in a way that
is useful for the comparison).
I am not sure I understand the above. Could you give an example where
certain flags might be set but are not useful for comparison?
--
PMatos
On 19/07/11 16:41, Richard Henderson wrote:
Note that while RX has one mode for floating-point, it has
two other modes to deal with instructions that fail to set
all of the flags (or fails to set the flags in a way that
is useful for the comparison).
Depending on how regular your instructions ar
On 19/07/11 16:36, Richard Henderson wrote:
But I am still confused as to how GCC matches them. Is *_flags any
special name GCC loops for (doubtful)?
No, and as you can see from the leading "*" in the name, the
name is not actually visible as a pattern.
Thought so... :)
As an experiment, p
On 07/19/2011 01:48 AM, Paulo J. Matos wrote:
> I have been looking at the rx port. Seems to be very similar to mine
> in that it has an add and adc where both set the flags and no
> explicit hard register for cc. Mine is actually simpler in that there
> is only CCmode since we don't have floating
On 07/19/2011 08:08 AM, Paulo J. Matos wrote:
> So, this seems to have to do with the post-reload comparison optimization
> pass Richard mentioned.
Exactly.
> But I am still confused as to how GCC matches them. Is *_flags any
> special name GCC loops for (doubtful)?
No, and as you can see from
On 19/07/11 16:06, DJ Delorie wrote:
What's the point of the second define insn? The first insn seems to
take us from expansion to asm generation so I can't see where the
second one will come into play except in an expansion after reload
but that doesn't happen, right?
IIRC it has to do with op
> What's the point of the second define insn? The first insn seems to
> take us from expansion to asm generation so I can't see where the
> second one will come into play except in an expansion after reload
> but that doesn't happen, right?
IIRC it has to do with optimizing away compare instructi
On 18/07/11 17:53, Richard Henderson wrote:
Otherwise, have a look at the mn10300 and rx ports.
What's the idea behind the rx port *_flags alternative define_insn?
For example:
(define_insn "abssi2"
[(set (match_operand:SI 0 "register_operand" "=r,r")
(abs:SI (match_operand:S
On Jul 19, 2011, at 4:21 AM, Paulo J. Matos wrote:
> On 18/07/11 19:00, Richard Henderson wrote:
>>
>>> "Specifically represent... the carry flag" means using the CCmode
>>> style of condition code handling, right?
>>
>> Yes.
>
> hummm, we are still using the old mode for condition code handli
On 19/07/11 11:20, Paulo J. Matos wrote:
For GE, shouldn't you also need CC_FLAG_Z ?
I just got it! :) No need for CC_FLAG_Z!
--
PMatos
On 18/07/11 17:53, Richard Henderson wrote:
Otherwise, have a look at the mn10300 and rx ports.
Looking at rx.c, flag_from_code:
static unsigned int
flags_from_code (enum rtx_code code)
{
switch (code)
{
case LT:
case GE:
return CC_FLAG_S;
...
For GE, shouldn't you also n
On 19/07/11 09:21, Paulo J. Matos wrote:
hummm, we are still using the old mode for condition code handling. From
what you're saying we need to use the new CCmode. I was looking at the
internal documents and even though it doesn't seem required to have a
hard register to keep the condition codes,
On 18/07/11 17:58, Ian Lance Taylor wrote:
Look at add3_cc in gcc/config/i386/i386.md. Look at how
add3_doubleword splits to use it.
Thanks Ian, from what Richard said I need an add that doesn't modify
carry in order to follow the approach there. Since I don't I guess I
have to look for ho
On 18/07/11 17:53, Richard Henderson wrote:
Therefore in order to expose the carry flag
before reload, you must have an add instruction that does not modify the
carry. Some processors have this in the form of a "load-effective-address"
instruction.
An add instruction that doesn't modify carry.
On 18/07/11 19:00, Richard Henderson wrote:
"Specifically represent... the carry flag" means using the CCmode
style of condition code handling, right?
Yes.
hummm, we are still using the old mode for condition code handling. From
what you're saying we need to use the new CCmode. I was loo
On 07/18/2011 10:29 AM, Paul Koning wrote:
> Why an add instruction? Is that in the case where address arithmetic
> requires separate adds?
I don't recall. Probably to do with some edge case of reloading addresses.
I know that this affects m68k, which is even CISC-y-er in its addressing
modes th
On Jul 18, 2011, at 12:53 PM, Richard Henderson wrote:
> On 07/18/2011 08:01 AM, Paulo J. Matos wrote:
>> The problem is, if addhi3 expands into two insn:
>> (define_insn "addqi3"
>> [(set (match_operand:HI 0 "nonimmediate_operand" "=c")
>> (plus:HI (match_operand:HI 1 "general_operand"
"Paulo J. Matos" writes:
> Where the format specifiers b and t choose the top and bottom 16 bits
> of each operand. add is a 16bit addition operand and addc takes carry
> flag into consideration. Now, there are a lot of simple manipulations
> that can be made if I release GCC from always outputti
On 07/18/2011 08:01 AM, Paulo J. Matos wrote:
> The problem is, if addhi3 expands into two insn:
> (define_insn "addqi3"
>[(set (match_operand:HI 0 "nonimmediate_operand" "=c")
> (plus:HI (match_operand:HI 1 "general_operand" "%0")
> (match_operand:HI 2 "general_opera
Hello,
I am trying to size-optimise one of our instructions. That's addhi3.
HImode is 32 bits and QImode is 16bits, which is what our processor
instructions work with.
So generally an addhi3 looks like:
(define_insn "addhi3"
[(set (match_operand:HI 0 "nonimmediate_operand" "=c")
(
21 matches
Mail list logo