Hi Mike,
And why is that a problem? You get to write arbitrarily complex C code that
can depend upon insn and operands.
Ah - I did not know this. I thought that you had to stick to RTL
expressions in the definition of attributes. Thanks for letting me know
otherwise.
Cheers
Nick
Hi Richard,
What is length used for in the rx port? I don't see any branch shortening
going on here; out of range branches are completely handled by the assembler.
You might be better off simply deleting the length attribute, so that the
compiler skips the bulk of the shorten_branches pass.
On Mar 17, 2011, at 5:31 AM, Nick Clifton wrote:
>> You can set up the correct length even without using separate patterns.
>
> The problem is
And why is that a problem? You get to write arbitrarily complex C code that
can depend upon insn and operands. I presume that you can do that.
See:
> What is length used for in the rx port?
We have a local patch that uses the length to decide if/when to align
labels; it goes along with the label alignment change I made a while
back. However, the patch works best in 4.5 (align patch not
backported) and there are other optimization problems w
On 03/17/2011 05:31 AM, Nick Clifton wrote:
> So really I think that I should be defining the ADJUST_INSN_LENGTH macro to
> handle these patterns. I'll look into that.
What is length used for in the rx port? I don't see any branch shortening
going on here; out of range branches are completely h
Hi Andrew,
+ (set_attr "length" "5")] ;; Worst case sceanario. FIXME: If we defined
separate patterns
+);; rather than using iterators we could specify
exact sizes.
You can set up the correct length even without using separate patterns.
The problem is that t
On Mar 16, 2011, at 12:05 PM, Andrew Pinski wrote:
>> + (set_attr "length" "5")] ;; Worst case sceanario. FIXME: If we defined
>> separate patterns
>> +);; rather than using iterators we could
>> specify exact sizes.
>
> You can set up the correct length even with
On Mar 16, 2011, at 10:12 AM, Richard Henderson wrote:
> On 03/16/2011 04:48 AM, Nick Clifton wrote:
>> (peephole): Add peephole to combine zero- and sign- extending
>> loads with arithmetic instructions.
>
> Do you really need peepholes for this? I would have thought that
> merely addi
On Wed, Mar 16, 2011 at 4:48 AM, Nick Clifton wrote:
> Hi Guys,
>
> I am checking in the attached patch to fix some regressions in the RX
> port with regard to alignment and addressing modes. With this patch
> applied I have 18 fewer failures in the GCC testsuite.
> + (set_attr "length" "5
Hi Richard,
Do you really need peepholes for this? I would have thought that
merely adding the instruction patterns for this would have been
enough to encourage combine to do its job merging these patterns...
I thought so too, but I found in my tests that combine was missing
plenty of cases
On 03/16/2011 04:48 AM, Nick Clifton wrote:
> (peephole): Add peephole to combine zero- and sign- extending
> loads with arithmetic instructions.
Do you really need peepholes for this? I would have thought that
merely adding the instruction patterns for this would have been
enough to
Hi Guys,
I am checking in the attached patch to fix some regressions in the RX
port with regard to alignment and addressing modes. With this patch
applied I have 18 fewer failures in the GCC testsuite.
Cheers
Nick
gcc/ChangeLog
2011-03-16 Nick Clifton
* config/rx/rx.h (JUMP_
12 matches
Mail list logo