From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Bill Currie Cc: Joern Rennecke , ak@muc.de, egcs@cygnus.com Subject: Re: Feature request: ability to describe x86 register halves as contraints. Date: Thu, 02 Jul 1998 01:39:00 -0000 Message-id: <24030.899359722@hurl.cygnus.com> References: <359AFFE1.26F8@tssc.co.nz> X-SW-Source: 1998-07/msg00078.html 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. > In that case, should I submit my patches anyway so at least they won't > get lost? Also, I would like feedback on what I've done from > knowledgable people. 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. 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. > > However, I'm curious how you deal with memory subregs or register > > subregs that get spilled, then loaded from memory. > > Hmm... now, I could have missed something, but the existing i860 md file > has relatively few references to subregs. The only time I had any real > problems was getting MULSI3 to work cleanly. This required hacking in > use of strict_low_part, probably to get around this very issue. I might > even find a cleaner solution. 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". 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)) 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. > 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. > > 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. jeff