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
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 17:58, Ian Lance Taylor wrote:
Look at addmode3_cc in gcc/config/i386/i386.md. Look at how
adddwi3_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
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
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
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 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 handling. From what
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:SI 1
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
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
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 the
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 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,
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
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 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
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)
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_operand cwmi)))]
Paulo J. Matos pocma...@gmail.com 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
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 %0)
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
21 matches
Mail list logo
