Re: AVR C++ - how to move vtables into FLASH memory
As I can see in my first post I would like to modify gcc AVR backend to support new feature – putting vtables into FLASH not SRAM. That’s why I sent my message here. Ok, I’ve studied a little bit gcc sources, I’ve found sections responsible for generating different register loading instructions, and indeed there is no information telling to the compiler how to load data from FLASH. This is easy to correct, I suppose. But I have no idea how compiler generates code responsible for loading pointers from vtable. I found code responsible for generating vtable itself. So please, can anybody point me to the peace of code responsible for loading pointers from vtables?
4.3 weekly snapshots bot broken?
It seems the bot or whatever that generates the weekly snapshots has stopped working for the 4.3 branch. I would have expected a new snapshot 2-3 days ago but found nothing on the mirrors. (And there has been commits since the last snapshot.) /Mikael
Re: Address mode offset spill
2009/6/16 Jeff Law : > Ian Lance Taylor wrote: >> >> daniel tian writes: >> >> >>> >>> There is a problem I encountered. I port gcc to 32bit RISC. The >>> LOAD/STORE only has 8bit displacement. If the immediate displacement >>> larger than 256, the displacement must be force into register. In >>> addition, if the immediate is larger than 512, it can only move into >>> one specified register R0. >>> >>> Like: >>> >>> LW R2 (R1) #252 ;; means R2 = Mem(R1 + 255) >>> >>> LW R2 (R1) #508;; it is wrong. immediate 508 should force into >>> register first. >>> >>> >>> LW R2 (R1) #0x500;; it is wrong, immediate 0x500 should force into >>> register R0 first. >>> >>> Now, for immediate movement, it is achieved to move large immediate. >>> But I don't know how to make the address mode legitimate. Now I try to >>> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But >>> cc1 still crashed, when the frame size is larger than 255. Do I miss >>> something? >>> >> >> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in >> TARGET_SECONDARY_RELOAD. I don't know why cc1 crashed, you will have to >> debug that. >> > > LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- > LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific approaches for > reloading can generate more efficient code than the generic code in reload. > The generic code should be producing correct, though potentially > inefficient code. > > I do agree that the target is going to need secondary reload support. > > jeff > You mean before LEGITIMIZE_RELOAD_ADDRESS, cc1 must generate the correct RTL code, regardless of whether efficient or not. Take the immediate load for instance, should I generate the the right code in "movm" expander? I mean ,first the larger immediate data will move into a pseduo register, then I insert a RTL code, first move to R0, then R0 move to the pseduo register. Right? Now I just force the larger immedate into a register, and let the reload to move the immediate into R0 register.
Re: 4.3 weekly snapshots bot broken?
On Wed, 17 Jun 2009, Mikael Pettersson wrote: > It seems the bot or whatever that generates the weekly snapshots > has stopped working for the 4.3 branch. I would have expected a > new snapshot 2-3 days ago but found nothing on the mirrors. > (And there has been commits since the last snapshot.) If you are interested in following the fine points of breakage of individual snapshots or other individual jobs run from cron, you should follow the gccadmin and overseers lists, where you would have seen the message showing the breakage and the subsequent discussion of the fix. -- Joseph S. Myers jos...@codesourcery.com
Re: Address mode offset spill
Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted from file *.23.greg :
(insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
(const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
(mem:SI (plus:SI (reg/f:SI 14 R14)
(const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
{store_si} (nil)
(nil))
this is not allowed in my RISC chip. And This doesn't go through the
reload macro. Is this need to solve in secondary reload?
2. Here is the RTL code in file *.23.greg:
(insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
(plus:SI (reg:SI 7 R7)
(const_int 2064 [0x810]))) 45 {rice_addsi3}
(insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
(insn_list:REG_DEP_ANTI 79 (nil
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
(const_int 2076 [0x81c]))
(nil)))
which is not legal in my risc chip. In MD file, I 've already defined
the addsi instruction pattern which only allows the 2nd operand with
less than 512. I don't know how did this happen. I mean I do know this
RTL comes from gcc optimization combination, but how it , which should
be an unrecognizable RTL, becomes recognizable RTL. Does it also need
the secondary reload macro to handle?
And last question, resulted from my gcc4.0.2 porting version, there is
still no TARGET_SECONDARY RELOAD target hook existance. So I should
achieve it with the macro SECONDARY_RELOAD_CLASS,
SECONDARY_INPUT/OUTPUT_RELOAD_CLASS. Can anybody give me a hint about
what 's distinction between SECONDARY_RELOAD_CLASS, and
SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.
Any suggestion is appreciated.
Thank you again for your guys helping me so much. Thank you.
Daniel. Tian
Re: "plugin"-ifying the MELT branch.
On Tue, Jun 16, 2009 at 7:30 PM, Basile STARYNKEVITCH wrote: > Diego Novillo wrote: >> >> On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote: >> >> >>> >>> Basile, people are saying that MELT no longer belongs in a branch of >>> the GCC repository because now that plug-ins are supported, MELT no >>> longer needs to modify GCC itself and can be maintained independently. > > MELT is not pluginified yet. So it will stay some time as a branch, because > today it cannot be a plugin (for various small technical details). My comment was to the new "branch" you were about to create where the MELT plugin will materialize. And yes, Janis got it right. Richard.
Re: 4.3 weekly snapshots bot broken?
Joseph S. Myers schrieb: If you are interested in following the fine points of breakage of individual snapshots or other individual jobs run from cron, you should follow the gccadmin and overseers lists, where you would have seen the message showing the breakage and the subsequent discussion of the fix. Is it possible to subscribe to those, or can the public only follow via the web archives?
Re: "plugin"-ifying the MELT branch.
Richard Guenther wrote:
On Tue, Jun 16, 2009 at 7:30 PM, Basile
STARYNKEVITCH wrote:
Diego Novillo wrote:
On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote:
Basile, people are saying that MELT no longer belongs in a branch of
the GCC repository because now that plug-ins are supported, MELT no
longer needs to modify GCC itself and can be maintained independently.
MELT is not pluginified yet. So it will stay some time as a branch, because
today it cannot be a plugin (for various small technical details).
My comment was to the new "branch" you were about to create where the
MELT plugin will materialize. And yes, Janis got it right.
I understood that I should not create a new branch for MELT as a plugin.
So I won't, and the pluginification of MELT becomes less a priority for
me (at least for the moment; it might change in 2010.).
Honestly, I was surprised by the reactions to my email. Very probably a
cultural problem, or perhaps a different perception of why plugins could
be useful inside GCC.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Address mode offset spill
daniel tian writes:
> Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
> before I add the second_reload macro. There are two problems happened.
> 1. there is a RTL code which move the memory data to another memory
> location. RTL extracted from file *.23.greg :
>
> (insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
> (const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
> (mem:SI (plus:SI (reg/f:SI 14 R14)
> (const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
> {store_si} (nil)
> (nil))
>
> this is not allowed in my RISC chip. And This doesn't go through the
> reload macro. Is this need to solve in secondary reload?
This kind of thing will be generated during reload, but should be
cleaned up during reload. If it is not, it suggests that perhaps you
are not checking REG_OK_STRICT as required, or that your predicates or
constraints are wrong. Or there may be some other explanation.
> 2. Here is the RTL code in file *.23.greg:
> (insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
> (plus:SI (reg:SI 7 R7)
> (const_int 2064 [0x810]))) 45 {rice_addsi3}
> (insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
> (insn_list:REG_DEP_ANTI 79 (nil
> (expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
> (const_int 2076 [0x81c]))
> (nil)))
>
> which is not legal in my risc chip. In MD file, I 've already defined
> the addsi instruction pattern which only allows the 2nd operand with
> less than 512. I don't know how did this happen. I mean I do know this
> RTL comes from gcc optimization combination, but how it , which should
> be an unrecognizable RTL, becomes recognizable RTL. Does it also need
> the secondary reload macro to handle?
The insn was recognized as rice_addsi3, so take a good look at that insn
and make sure the predicates and constraints reject the 2064.
> And last question, resulted from my gcc4.0.2 porting version, there is
> still no TARGET_SECONDARY RELOAD target hook existance. So I should
> achieve it with the macro SECONDARY_RELOAD_CLASS,
> SECONDARY_INPUT/OUTPUT_RELOAD_CLASS. Can anybody give me a hint about
> what 's distinction between SECONDARY_RELOAD_CLASS, and
> SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.
Yes, in gcc 4.0.2 you need to use SECONDARY_RELOAD_CLASS. The docs
explain the difference. I can't recommend using gcc 4.0.2 as a porting
base; newer versions of gcc will generate better code.
Ian
Re: 4.3 weekly snapshots bot broken?
On Wed, 17 Jun 2009, Kai Henningsen wrote: > Joseph S. Myers schrieb: > > If you are interested in following the fine points of breakage of individual > > snapshots or other individual jobs run from cron, you should follow the > > gccadmin and overseers lists, where you would have seen the message showing > > the breakage and the subsequent discussion of the fix. > > Is it possible to subscribe to those, or can the public only follow via the > web archives? I believe you can subscribe to those lists. -- Joseph S. Myers jos...@codesourcery.com
Re: 4.3 weekly snapshots bot broken?
Joseph S. Myers wrote: > On Wed, 17 Jun 2009, Kai Henningsen wrote: > >> Joseph S. Myers schrieb: >>> If you are interested in following the fine points of breakage of individual >>> snapshots or other individual jobs run from cron, you should follow the >>> gccadmin and overseers lists, where you would have seen the message showing >>> the breakage and the subsequent discussion of the fix. >> Is it possible to subscribe to those, or can the public only follow via the >> web archives? > > I believe you can subscribe to those lists. > I can confirm that for overseers from personal experience. cheers, DaveK
Re: genrecog: ran out of alphabet
DJ Delorie writes: > genrecog uses strings to keep track of where it is, specifically, > digits and letters. I've got an insn that writes to more than 26 > registers. Would switching to something bigger than [A-Z] be > difficult? Perhaps using Japanese letters instead of English? ;-) That sounds like an awkward insn. The code currently uses upper case and lower case letters to mean different things, and tests for them using ISUPPER and ISLOWER. It uses strlen, strcmp, and strdup to manage these strings. Extending it to use some more transparent data structure sounds like a good idea, but I think it might be nontrivial. It would be nice if genrecog at least checked for an out of range letter. Ian
Re: Rationale for an old TRUNCATE patch
Adam Nemet writes: > Ian Lance Taylor writes: >> truncate has a machine independent meaning. > > Yes, I guess with your definition below it does. It's interesting though that > Jim had said the opposite in the excerpts posted by Jeff: > > And a later message from Jim: > > Truncate converts a value from a larger to a smaller mode in a machine > dependent way. > > A subreg just chops off the high bits. A truncate does not. The name might > be a little confusing, but the whole point of truncate is to have something > that operates differently than a subreg. > > Combine is clearly making an invalid transformation. I'm not entirely sure, but I don't think Jim said the opposite. He said that the way truncate works is machine dependent. I said that the output of truncate is machine independent. Since truncate is only defined for fixed-point modes, I think both statements are true. Ian
Re: AVR C++ - how to move vtables into FLASH memory
Tomasz Francuz writes: > Ok, I’ve studied a little bit gcc sources, I’ve found sections > responsible for generating different register loading instructions, > and indeed there is no information telling to the compiler how to load > data >> From FLASH. This is easy to correct, I suppose. But I have no idea >> how > compiler generates code responsible for loading pointers from > vtable. I found code responsible for generating vtable itself. So > please, can anybody point me to the peace of code responsible for > loading pointers >>From vtables? The build_vtbl_ref function. Ian
Re: 4.3 weekly snapshots bot broken?
Dave Korn writes: > Joseph S. Myers wrote: >> On Wed, 17 Jun 2009, Kai Henningsen wrote: >> >>> Joseph S. Myers schrieb: If you are interested in following the fine points of breakage of individual snapshots or other individual jobs run from cron, you should follow the gccadmin and overseers lists, where you would have seen the message showing the breakage and the subsequent discussion of the fix. >>> Is it possible to subscribe to those, or can the public only follow via the >>> web archives? >> >> I believe you can subscribe to those lists. >> > > I can confirm that for overseers from personal experience. While "overseers" sounds like it might be a cool list, in actual practice most of the traffic consists of "please change my e-mail address." Ian
New plugins repository page
I have created a wiki page to act as a repository of GCC plugins: http://gcc.gnu.org/wiki/plugins The page is linked from the main wiki page as well. Feel free to add new entries and other information that I was too lame to add. Diego.
Re: 4.3 weekly snapshots bot broken?
Ian Lance Taylor wrote: > Dave Korn writes: > >> Joseph S. Myers wrote: >>> On Wed, 17 Jun 2009, Kai Henningsen wrote: >>> Joseph S. Myers schrieb: > If you are interested in following the fine points of breakage of > individual > snapshots or other individual jobs run from cron, you should follow the > gccadmin and overseers lists, where you would have seen the message > showing > the breakage and the subsequent discussion of the fix. Is it possible to subscribe to those, or can the public only follow via the web archives? >>> I believe you can subscribe to those lists. >>> >> I can confirm that for overseers from personal experience. > > While "overseers" sounds like it might be a cool list, in actual > practice most of the traffic consists of "please change my e-mail > address." > > Ian So I discovered :-) I did it only temporarily for a while when there was a thread going on that I didn't want to miss any posts in if I didn't get explicitly Cc'd. I didn't hang around much longer after that ... cheers, DaveK
Re: 4.3 weekly snapshots bot broken?
On Wed, 17 Jun 2009, Ian Lance Taylor wrote: > While "overseers" sounds like it might be a cool list, in actual > practice most of the traffic consists of "please change my e-mail > address." And most of the gccadmin traffic is completely routine messages from cron - things don't break that often, and if they do in a way visible on the list then they are likely to be fixed quite soon. -- Joseph S. Myers jos...@codesourcery.com
Re: Rationale for an old TRUNCATE patch
Adam Nemet wrote: Jeff Law writes: Ian Lance Taylor wrote: Adam Nemet writes: I am trying to understand the checkin by Jeff Law from about 11 years ago: r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines * combine.c (simplify_rtx, case TRUNCATE): Respect value of TRULY_NOOP_TRUNCATION. Index: combine.c === --- combine.c(revision 19018) +++ combine.c(revision 19204) @@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) break; - if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT) + if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT + && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode), +GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0) SUBST (XEXP (x, 0), force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)), GET_MODE_MASK (mode), NULL_RTX, 0)); This optimization simplifies the input to a truncate by only computing bits that won't be eliminated by the truncation. Normally these are the bits in the output mode mask. Note that the optimization does not change the truncate into a low-part subreg, which would pretty automatically warrant the TRULY_NOOP_TRUNCATION check. I agree that this patch looks wrong in todays compiler. There should be no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. Based on reviewing my old notes, we do have to ensure that combine doesn't replace a TRUNCATE with a SUBREG as that can result in having a 32bit value that isn't sign-extended, which clearly causes MIPS64 ports grief. Thanks for the long information in your other reply. As I said in the original email, we are not turning a TRUNCATE into a SUBREG in this transformation. We're just simplifying the input expression to truncate with the knowledge that only the truncated mode bits are relevant from the input. At the end we are still left with a truncate expression but possibly with a simpler operand. Agreed. I think it's a distinct possibility that the patch in question just papered over the problem and the Oct 1998 patch actually fixed the problem. I've got no objections to removing the code you're referring to. Jeff Adam
gengtype & plugins.
Hello All
(In case you don't read gcc-patches@)
I just posted in http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01363.html
some thoughts & experiments about gengtype in plugins.
I came to the following tentative conclusions.
All this makes me think that
A. we should generate appropriately a $gccplugins/gtyp-input-plugins.list
B. we should install gengtype as gcc-gengtype at some appropriate place
C. we should document that, and update the documentation on how to
build plugins.
I don't know what mailing list is the better place to discuss that.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: gengtype & plugins.
On Wed, Jun 17, 2009 at 11:15, Basile STARYNKEVITCH wrote: >> All this makes me think that >> >> A. we should generate appropriately a $gccplugins/gtyp-input-plugins.list >> B. we should install gengtype as gcc-gengtype at some appropriate place >> C. we should document that, and update the documentation on how to build >> plugins. > > I don't know what mailing list is the better place to discuss that. This is the right forum. For the time being, I would just document that plugins wanting to use GGC should keep a gcc build tree around. If there is significant demand for GGC in the future, we could rethink this. I am hoping that not very many plugins will want/need GGC, but I'm frequently wrong. Diego.
Re: Rationale for an old TRUNCATE patch
Ian Lance Taylor writes: > I'm not entirely sure, but I don't think Jim said the opposite. He said > that the way truncate works is machine dependent. I said that the > output of truncate is machine independent. Since truncate is only > defined for fixed-point modes, I think both statements are true. OK but in that way every operation is machine dependent not just truncate. BTW, why is being fixed-point relevant here? >From that little excerpt I just gathered that maybe my misunderstanding of treating truncate as a blackbox was not completely without precedence. But anyway I think I understand now. JTBS, can you agree with other statement in my email?: > And IIUC this don't-care nature of the other bits that allows backends to > define the upper bits. For example to have sign-bit copies there in registers > to enforce the MIPS64 SI mode representation. And treating the don't care > bits outside SI mode in this way is true for any other SI-mode operations > performed on registers not just truncate, right? Hmm, nice. Thanks for all the explanations. Adam
Re: Rationale for an old TRUNCATE patch
Adam Nemet writes: > Ian Lance Taylor writes: >> I'm not entirely sure, but I don't think Jim said the opposite. He said >> that the way truncate works is machine dependent. I said that the >> output of truncate is machine independent. Since truncate is only >> defined for fixed-point modes, I think both statements are true. > > OK but in that way every operation is machine dependent not just truncate. Yes. > BTW, why is being fixed-point relevant here? Because truncating from DFmode to SFmode really is machine dependent, since it depends on the floating point representation being used. We use float_truncate for that. Ian
Faites vous élire Magistrat Juge au Tribunal de Commerce
ASSEZ D'INJUSTICES Défendez-vous. Cessez d'être les coupables. Avec la Coordination Nationale Des Indépendants - CNDI - sauvez les "petites" entreprises. Elles sont le tissu économique de la France, de notre pays, de notre patrie. Mobilisez-vous. Allez sur le site Internet : http://www.cndi.fr/ Faites-vous élire Magistrat Juge à votre Tribunal de Commerce Soyez le candidat de la Coordination Nationale Des Indépendants -CNDI -pour 1) Une Justice de qualité 2) Une Justice d'égalité 3) Une justice éthique et surtout pour faire adapter un Code du Commerce plus proche des "petites" entreprises. Rejoignez la Coordination Nationale Des Indépendants - CNDI - sur le site Internet : http://www.cndi.fr/ Pour ne plus recevoir de communication de notre part cliquez sur ce lien: http://ml.myreso.fr/form.php?a381c85da608be2c87f9
Registers safe across function calls
I'd like to be able to specify registers that are safe across function calls (without the need to save/restore) and I cannot figure out how to do this. I know that I can set these particular registers to '0' in CALL_USED_REGISTERS and then remove the call/restore in the prologue/epilogue, but the stack space is still reserved for the save/restore. I would like to just rely on the fact that these registers are safe across function calls and not reserve any stack space for them. Thanks in advance. -- View this message in context: http://www.nabble.com/Registers-safe-across-function-calls-tp24081065p24081065.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Registers safe across function calls
Please ignore this previous message... I found the error in my machine dependent code. Dobes wrote: > > I'd like to be able to specify registers that are safe across function > calls (without the need to save/restore) and I cannot figure out how to do > this. I know that I can set these particular registers to '0' in > CALL_USED_REGISTERS and then remove the call/restore in the > prologue/epilogue, but the stack space is still reserved for the > save/restore. I would like to just rely on the fact that these registers > are safe across function calls and not reserve any stack space for them. > Thanks in advance. > -- View this message in context: http://www.nabble.com/Registers-safe-across-function-calls-tp24081065p24081201.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: VTA guality assessment: better than -O0 ;-)
On Sun, Jun 14, 2009 at 11:17:32AM -0400, Daniel Jacobowitz wrote: > On Sat, Jun 13, 2009 at 10:08:39PM +0200, Jakub Jelinek wrote: > > I really think we need to do (limited) -fvar-tracking even for -O0, it is > > really bad that most arguments have wrong locations through the prologue, > > while at -O1 or above they often have correct location. > > We should just do the tracking inside of the prologue or for register > > variables, those that are stored into memory during the prologue and live in > > memory shouldn't be tracked outside of the prologue at -O0. > > I completely agree, this would make GDB more useful. --- gcc/var-tracking.c.jj 2009-05-04 16:46:38.0 +0200 +++ gcc/var-tracking.c 2009-06-17 17:48:58.0 +0200 @@ -1652,6 +1652,8 @@ track_expr_p (tree expr) if (MEM_SIZE (decl_rtl) && INTVAL (MEM_SIZE (decl_rtl)) > MAX_VAR_PARTS) return 0; + if (!optimize && TREE_CODE (expr) == VAR_DECL) + return 0; } return 1; decreased the -O0 -g -fvar-tracking debuginfo on the trunk quite a bit, I don't think there is any point in tracking VAR_DECLs that live in MEM, only PARM_DECLs (which during the prologue might move from registers) and VAR_DECLs that don't have MEM decl_rtl (at -O0 those are just vars with register keyword I believe from the ones var-tracking would track). Still, I think for -O0 -g -fvar-tracking we should note that the parms moved into their desired slots immediately (e.g. by pretending the register from which they have been stored was also clobbered on the same instruction). Jakub
Re: genrecog: ran out of alphabet
> That sounds like an awkward insn. The opcode swaps two register banks. 32 SETs total. > It would be nice if genrecog at least checked for an out of range > letter. Or used "ch-'a' < 32" tests, but would that work with EBCDIC build machines?
Re: genrecog: ran out of alphabet
DJ Delorie writes: >> That sounds like an awkward insn. > > The opcode swaps two register banks. 32 SETs total. Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit machine, using DImode will cut the number of operands in half. Ian
Re: genrecog: ran out of alphabet
> > The opcode swaps two register banks. 32 SETs total. > > Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit > machine, using DImode will cut the number of operands in half. They're DImode already, but I did figure out a workaround that reduces it to 16 SETs, so I'm all set. Still, a range check in genrecog would be nice ;-)
