From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Currie To: law@cygnus.com Cc: Joern Rennecke , ak@muc.de, egcs@cygnus.com Subject: Re: Feature request: ability to describe x86 register halves as contraints. Date: Fri, 03 Jul 1998 00:12:00 -0000 Message-id: <359BF4AB.1229@tssc.co.nz> References: <24030.899359722@hurl.cygnus.com> X-SW-Source: 1998-07/msg00117.html Jeffrey A Law wrote: > > In message < 359AFFE1.26F8@tssc.co.nz >you write: > > However, I get a successfull stage3 build and compare. Does that count? > Not really :-) You wouldn't believe the things I've seen pass 3-stage > the testsuite, commercial testsuites, etc. Actually, I've been getting problems still (broken long long constants at the moment), so I believe you. > Yes they would be greatly appreciated. If at all possible you should > send multiple patches -- one for each problem you encountered. Since > few of us know the i860 all that well, it would be quite helpful if > you could describe the problem and how your solution fixes the problem > so that we can better evaluate the change. Ok, I'll get started on splitting up my diff file and writing up what each set of diffs does. > It may also be the case that we'll need a copyright assignment from you > to use the changes -- depends on how big they are as a whole. Not a problem. I already have verbal permission from my employer, so I'll just need the forms (20k of diffs). > References to subregs mostly created by the compiler totally outside > the control of the backend. Furthermore, if you have predicates that > accept a "register_operand", then they also accept subregs. As would > "general_operand". Yeah, I think it was that which helped me come to my solution. > So consider a AND operation of two DImode registers (call them X & Y)) > The compiler may generate code like this: > > (set (reg:SI 0) (subreg:SI (reg:DI source1) 0))) > (set (reg:SI 1) (subreg:SI (reg:DI source1) 1))) > (set (reg:SI 2) (subreg:SI (reg:DI source2) 0))) > (set (reg:SI 3) (subreg:SI (reg:DI source2) 1))) > > (set (subreg:SI (reg:DI target) 0)) (and:SI (reg:SI 0) (reg:SI 2)) > (set (subreg:SI (reg:DI target) 1)) (and:SI (reg:SI 1) (reg:SI 4)) Bletch. And I believe the i860 WILL do that as there aren't any 64 bit and instructions. However, this doesn't cause a problem. > In this case word order doesn't matter. In other cases it will > (consider addition) and if some of the regs get spilled to memory > you'll change the meaning of the code because the meaning of the > subreg changes. I've only ever seen whole regs getting spilled (if I understand spilling). > > Also, I could be very wrong (especially because I'm not too sure what > > spilling is), but how often do subregs get spilled? > Not sure how to answer that. :-) They do get spilled. Since there's > generally fewer subregs than regs the total number of spills is smaller. > However, I suspect the percentage of subregs that gets spilled is high. > > > Hmm, just realised > > you may be referring to when reload.c strips the subreg info if the > > subreg is 0. I told push_reload (? bloody big functions) not to strip > > the subreg info if REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN. > It's more than that. :-) > > For example the compiler could have (subreg:SI (reg:DI) 1); then consider > what happens in the reg gets spilled to the stack -- you'll end up > with (subreg:SI (mem:DI) 1) which has a different meaning. > > reload can (and will) perform direct replacements of a REG with a MEM > expression. Other passes may do this too, but the register alloctors > and reload do it more than other passes. When this happens the meaning > of the code changes because the meaning of SUBREG changes depending on > what item is inside the SUBREG. Ah, we seem to be mis-communicating. I do not change the meaning of a SUBREG until it's time to actually emit the assembly code. The only change to SUBREG's meaning I make is the order of the subregs within a DI *register* pair. > > > impression that how the word of a subreg is interpreted changes based > > > on what the inner object is. > > > > Do you mean whether it's a REG or a MEM object? Yes, that's exactly > > what I do in final.c as it is selecting the register name. > Ouch! Danger. Danger. Danger. This is not safe. See above about > replacement of REG with MEM expressions. But that is done long before printing the assembly code, is it not? NOTE: I *HAVE* seen my SUBREG definition hacking causing problems, *BUT* that (so far) has been caused by incorrect constraints on insns, which I promptly fixed as I found them. Somehow, I think I will have to submit those patches (with *DETAILED* explanations:) just to show that I think I think I sortof know what I'm doing:) I'll spend the weeked forward porting my patches to the most my recent CVS grab (2amNZST daily) and writing them up (Friday here at the moment:). Bill -- Leave others their otherness