I'm am fixing some reload bugs for AVR.
In a couple of situations an address is formed which included a SUBREG
expression.
I am not sure how I should be handling these. Initial attempts produce
sub-optimal code - and/or reload failures, so thought is a good idea to
get some advise!
Either
For AVR I get failures of:
FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect "vectorized
1 loops" 1
FAIL: gcc.dg
Help !
gcc.dg/tree-ssa/loop-35.c is a test that looks for "Executing store motion" in
dump-tree-lim-details
As the load and store of memory location should be pulled out of loop.
This works for 3 out of 4 tescases. But on AVR target test3() will fail.
The only difference between this and te
Hi,
In the process of fixing tests for AVR and other small targets I have
come across issues with profile
tests in gcc/dg/struct that affect all targets and I would like reviewed
so I can raise patches to rectify them correctly.
Both involve random creating structures then setting and checkin
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
This worked just as your described after I added test of
reg_equiv_constant[] inside L_R_A .
So I guess that looks like the fix for bug I post
Thank you very much for reply. reload is such a lonely place!
TBH, it sounds like the opposite: LEGITIMIZE_RELOAD_ADDRESS should
not be handling this address at all.
Yes but reload will not do anything before call to L_R_A. So in practice
that would mean L_R_A has
to check reg_equiv_constant[re
Thanks Ian!
I found it in function.c (expand_function_start)
emit_move_insn (r_save, virtual_stack_vars_rtx);
Whereas it should be
emit_move_insn (r_save, targetm.builtin_setjmp_frame_value ());
to match same construction used for setjmp.
thanks for help!
Ian Lance Taylor wrote:
how I can patch testcase
correctly for AVR or post a bug.
best regards
Andy
Manuel López-Ibáñez wrote:
2008/5/20 Andy H <[EMAIL PROTECTED]>:
I came across this odd issue with testsuite test Wconversion-5.c and AVR
target.
I should get warning going from a unsigned value that is wider than
I came across this odd issue with testsuite test Wconversion-5.c and AVR
target.
I should get warning going from a unsigned value that is wider than
signed result.
As I am not skilled in the art of the all conversions rules. I would
appreciate some guidance before I report this as bug.
FYI
I want to add target specific tests for AVR.
These would be testcases for PR that fail related to AVR back end
problems - rather than testcases for generic PR.
Do I just add them to directory testsuite/gcc.target/avr? Or are there
some other configuration steps needed?
Andy
Take at look at AVR target which is very similar.
Here onluy "d" constrained register accept constants (they are call used
registers too)
The AVR move pattern (*reloadinqi) has multiple constrain options "d"
against "i" being relevant. So check you have all the combinations
defined. You omit
Thank you so much.
I can test it easily and will let you know of any divergence from
original other than the those you mention.
Andy
Janis Johnson wrote:
On Sat, 2008-04-05 at 06:57 -0400, Andy H wrote:
There are several test in testsuite that use trampolines that are still
run with
There are several test in testsuite that use trampolines that are still
run with dejagnu switch set to no_trampolines.
Its on my TODO list for AVR target but a recent email reminded me that
it affects testing of other targets than can't or won't support
trampolines.
Theres an old patch by
no_trampolines Dejagnu switch will omit many but not all trampoline dependent
tests.
Nested function are ok - but anything that takes an address of a nested function will use trampoline.
They can be hard to find as testcases are devilish at hiding that part!
For example:
gcc.c-torture/com
I have been working on AVR port and have come across many instances
where poor code is produced due to the absence of effective forward
propagation of operands before register allocation.
The AVR target in particular benefits from register lowering pass as
many physical registers and instructi
Hi,
I have problem with data flow and combine that is causing ICE with
experimental build. Despite all efforts to blame my own target changes,
I have reached the conclusion that this is a gcc COMBINE bug, but seek
your advice before filing a bug report.
The problem seems to be that the LOG_LI
Paolo,
As you suggested, I moved the extra fwprop nearer combine, just after
split - but it failed to propagate anything.
The reason is that immediately post split the data flow is reflecting
cross dependencies between Word and subreg U/D. So the USE of just 1
QImode subreg of SImode regis
I very grateful for your help and wisdom
Testcase and MD Patch attached
unsigned long f (unsigned char *P)
{
unsigned long C;
C = ((unsigned long)P[1] << 24)
| ((unsigned long)P[2] << 16)
| ((unsigned long)P[3] << 8)
| ((unsigned long)P[4] << 0);
return C;
}
Index: avr.md
I tried extra fwprop pass and got some very interesting results!
First "caveat" I just cut/pasted extra pass into list - nor worrying
about detail.
NEXT_PASS (pass_rtl_fwprop);
NEXT_PASS (pass_local_alloc);
To show effects here is assembler code dump (which is easier to read
than R
Dave and Jeff,
Here are more details and I have include testcase, splitter patterns and
RTL dump to show problem in more detail.
The testcase is:
unsigned long f (unsigned char *P)
{
unsigned long C;
C = ((unsigned long)P[1] << 24)
| ((unsigned long)P[2] << 16)
| ((unsigned long)P
After some digging, I can confirm local-alloc.c is creating OR Rx,0
instructions but not simplifying them
local-alloc.c is not the problem - but right now it the only help I'm
getting for post split optimization.
This occurs when source registers are replaced with equivalent constant
using va
21 matches
Mail list logo
