Is there a good way of creating an assembler comments directly from RTL?
I want to be able to add debugging/explanation strings to assembler listing
(GAS). Unfortunately I want to do this from RTL prologue and epilogue (and
thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where it would be easy
Attached is patched for 4.1.0 head that changes AVR to use RTL
prologue/epilogue generation.
This also should also fix the c++ bug caused by the existing code using the
function name as a label. (sorry the PR escapes me!)
It generates same code with following exceptions:
Small stack adjustmen
I am stumped and hope someone more skilled can give me some clues to
solve this problem I have 4.3/4.4 gcc.
I have created RTL define/splits for AVR port logical operation
(AND,IOR etc). These split larger mode operations in to QImode
operations. I also created similar splitters for zero_ex
Jeff,
thanks for help - I desparately need ideas - this problem is driving me
nuts
The RTL for IOR Rx,0 does use subregs (since I use simplify_gen_subreg
in splitter.)
Perhaps I should generate new pseudo QI registers instead before
reload?
Is there any particular function or pass that
Jeff,
thanks again for suggestions.
As I understand it (perhaps wrongly), actual splitting only occurs
after combine pass (by split1 pass).
The combine, does, match one of my patterns (lshift:SI
(zero_extend:QI), 8/16/24). The other splitters (zero_extend) are
"matched" initially - sinc
Dave and Jeff,
(sorry if you get more than one copy of this email, it's playing up!)
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
RTL dumps for Combine pass and ASMCONS (last one before local-alloc)
COMBINE
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
insn_cost 2: 4
insn_cost 6: 16
insn_cost 7: 12
insn_cost 8: 16
insn_cost 9: 16
insn_cost
I still have to try extra fwprop pass to confirm this solves the issue.
But it does seem that the missing piece is effective constant
propagation + simplification after splits and subregs - which is
currently ineffective in local-alloc (or any later pass)
Adding extra pass indeed seems a po
Yes - the other approach is to lower at RTL expand.
Unfortunately there is no practical way to lower arithmetic and compare
operations. reload can add arithmetic which messes the "carry"
handling attempts. So we end up with mixed higher level and lower level
RTL.
This mixture then causes ot
Splitters on MovMM are problematic.
One problem is that it creates issues with base pointers. AVR base
pointer are limited to 64 byte offsets - after that they are inline
additions (and perhaps subtractions). So splitting such a move in a
large mode is a world of hurt. A future endeavour perha
fwprop is a good suggestion. If that also simplifes substitutions, it
may be the magic bullet to collapse all of the code. I will try latter
tonite.
-Original Message-
From: Paolo Bonzini <[EMAIL PROTECTED]>
To: Andy H <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; gcc@g
Paolo
I placed extra fwprop before local-alloc as this was just before NOP
got created and after splitting.
Putting fwprop after combine is no problem - but is too early - none of
the patterns would be split at that time - preventing byte level
propagations.
As register usage as well as c
If I understand correctly:
Prop. of "0" causes simplfy-rtx to create NOP from OR Rx,0
This NOP (deletion?) creates another set of potential uses - as now
the prior RHS def now passes straight thru to a new set of uses - but
we miss those new uses. (which in the testcase are often 0)
I will
Jeff,
I take your point and will go back over my splitters as I know one
instance in which a splitter can create such an issue.
(I should checlk for a constant operand after simplifying an operand).
In the cases I looked at before this was not the situation.
Each splitter - or subreg loweri
The deed is done!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519
I added a patch but it needs more expertise than I have.
-Original Message-
From: Ian Lance Taylor <[EMAIL PROTECTED]>
To: Andy H <[EMAIL PROTECTED]>
Cc: GCC Development
Sent: Mon, 10 Mar 2008 1:32 pm
Subject: Re: Com
I noticed
Stack register is missing from ALL_REGS.
Are registers 16bit? Is just one required for pointer?
Andy
That looks correct.
Be aware that support for handling long long operands (64 bits) - or
doubles is not well supported on AVR. So you may expose some problems
with this.
We currently have long long disabled in testsuite testing to avoid
noise. At some point I hope to switch it back on to
During the process of fixing setjmp for AVR target, I needed to define
targetm.builtin_setjmp_frame_value () to be used in
expand_builtin_setjmp_setup().
This sets the value of the Frame pointer stored in jump buffer.
I set this "value" to virtual_stack_vars_rtx+1 (==frame_pointer)
Receiver de
I already have nonlocal_goto, and nonlocal_goto_receiver.
These expect saved frame pointer to be virtual_stack_vars_rtx+1.
For setjmp the value is determined by
targetm.builtin_setjmp_frame_value - which I defined and is correct.
But for goto the value is created by some other code - which a
I think my last email crossed your reply - so apolgies for restating:
expand_builtin_nonlocal_goto is fine. This perform stack restore,
extracts frame pointer value and does jump.
reciever is fine - this jump destination does restore of frame pointer.
The problem I have is with frame pointer
Richard,
I appreciate the extra input.
I agree with what you say. The target should not be doing middle-end
stuff .
The inc/dec and (Rxx) != (frame pointer) parts just reload using
pointer class
which is a one extra register than base pointers but the extra reg
cannot take offset.
Howe
Again thank you and Denis for your comment.
Here is what I deduce from code and Denis comments - I am sure he (and
others) will correct me if wrong :-)
The main issue is that we have one pointer register that cannot take
offset and two base pointers with limited offset (0-63).
Reload pro
22 matches
Mail list logo
