This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for regression PR target/28490 (IA64 ICE)


Steve Ellcey wrote:
I was talking to someone locally and he wondered why we didn't generate:
	addl r35 = @ltoff(cl_symbols#+8), r1
	;;
	ld8 r35 = [r35]

Good question. I was looking at the psabi yesterday, and I noticed it said "@ltoff(expr)" and I was kind of wondering why we were going to so much trouble to avoid using an expr here. I didn't see expr defined anywhere, but presumably anything that qualifies as a CONST is a valid expr here. We probably just screwed up in the beginning, and never noticed the mistake.


I was looking at how to keep the addend attached to the symbol but I am
confused by the code in ia64_expand_move.  It seems like, if addend_lo
is zero, we ignore addend_hi.  Is it not possible for addend_lo to be
zero and addend_hi to be non-zero?  If so do we do the right thing?  I
don't understand how.

Note that op1 is not set in this case, and hence op1 continues to be a CONST that contains the addend. It is only when we set op1 to sym that we have a separate addend that we need to handle.


Apparently large addends are OK to use in @ltoff, but not small ones. Maybe this was a misguided optimization attempt, i.e. we extract out all of the small offsets thinking that we can fold them into following code, either by folding them into an address add, or an addressing mode. The assumption here is that we would have common base addresses (the large offsets), and then the small offsets would all be relative to the base address. This would reduce the number of got entries we need. However, this would work better if we have reg+offset addresses which we don't. This trick is used on a number of other targets, but may not make sense on IA-64. Maybe it was accidentally copied in from another target without realizing that it isn't a good idea here. Also, this would work better if we had a really good auto-increment optimization pass, which we don't. Unfortunately, all I can do at the moment is speculate. I can comment on this in more detail when I get back.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]