* Constrainst for individual registers @ 2011-10-24 8:09 איליה לסוחין 2011-10-24 19:41 ` Georg-Johann Lay 0 siblings, 1 reply; 4+ messages in thread From: איליה לסוחין @ 2011-10-24 8:09 UTC (permalink / raw) To: gcc-help Hi, I'm doing some modifections to the avr backend to suit my needs. I would like to add new constrainst for individual registers to use in inline assembly blocks and i was wondering what is the correct way of doing this? in gcc-4.5, i've added a new class for each register to reg_class, REG_CLASS_NAMES and REG_CLASS_CONTENTS, made a need constrainst for each register using its class and it worked as expected. i tried to do the same in gcc-4.7 and i got: internal compiler error: in find_costs_and_classes, at ira-costs.c:1704. So i was wondering whether i did the wrong thing or just forgot to update some target hook. Thanks, Ilya. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Constrainst for individual registers 2011-10-24 8:09 Constrainst for individual registers איליה לסוחין @ 2011-10-24 19:41 ` Georg-Johann Lay 2012-01-25 6:56 ` Ilya Lesokhin 0 siblings, 1 reply; 4+ messages in thread From: Georg-Johann Lay @ 2011-10-24 19:41 UTC (permalink / raw) To: ilya; +Cc: gcc-help > Hi, > I'm doing some modifections to the avr backend to suit my needs. > > I would like to add new constrainst for individual registers to use in > inline assembly blocks and i was wondering what is the correct way of > doing this? Not on topic: You can have a look at GCC's "Specifying Registers for Local Variables" feature: http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html#Local-Reg-Vars For example, this enables you to interface non-ABI assembler functions with C code without patching the compiler. Moreover, introducing individual register classes will result in a zoo of constraints for 8-bit, 16-bit, 32-bit registers. > in gcc-4.5, i've added a new class for each register to reg_class, > REG_CLASS_NAMES and REG_CLASS_CONTENTS, made a need constrainst for > each register using its class and it worked as expected. > > i tried to do the same in gcc-4.7 and i got: > internal compiler error: in find_costs_and_classes, at ira-costs.c:1704. You will have to debug the compiler proper. Notice that hooks like HARD_REGNO_MODE_OK put additional restrictions on registers/mode combinations. > So i was wondering whether i did the wrong thing or just forgot to > update some target hook. > > Thanks, > Ilya. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Constrainst for individual registers 2011-10-24 19:41 ` Georg-Johann Lay @ 2012-01-25 6:56 ` Ilya Lesokhin 2012-01-26 16:24 ` Georg-Johann Lay 0 siblings, 1 reply; 4+ messages in thread From: Ilya Lesokhin @ 2012-01-25 6:56 UTC (permalink / raw) To: Georg-Johann Lay; +Cc: gcc-help Hi, I've used your suggestion of "Specifying Registers for Local Variables" and found out that code it generates gives better results than my method. Unfortunately, a recent there on the subject: http://gcc.gnu.org/ml/gcc/2012-01/msg00305.html got me worried, so I would like to hear what you (or anyone familiar with the subjet) know about the status of implementation of "Local register Variables" in the AVR backend in gcc-4.5.3 and if it's better in newer gcc's. Specifically, I would like to know if you believe the following code is safe (assuming _mul16x16_32 is implemented correctly): DWord_t mul16x16_32(uint16_t x, uint16_t y)__attribute__((always_inline)); DWord_t mul16x16_32(uint16_t x, uint16_t y) { register uint16_t r24_25 asm ("r24") = x; register uint16_t r22_23 asm ("r22") = y; register uint16_t r30_31 asm ("r30"); register uint16_t r20_21 asm ("r20"); asm ( " call _mul16x16_32" "\n\t" : "=&r" (r20_21), "=&r" (r30_31) : "r" (r24_25), "r" (r22_23) : "r0", "r1", "cc" ); DWord_t Result; Result.High = r20_21; Result.Low = r30_31; return Result; } Thank, Ilya. On 10/24/11, Georg-Johann Lay <avr@gjlay.de> wrote: >> Hi, >> I'm doing some modifections to the avr backend to suit my needs. >> >> I would like to add new constrainst for individual registers to use in >> inline assembly blocks and i was wondering what is the correct way of >> doing this? > > Not on topic: You can have a look at GCC's "Specifying Registers for > Local Variables" feature: > http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html#Local-Reg-Vars > > For example, this enables you to interface non-ABI assembler functions > with C code without patching the compiler. > > Moreover, introducing individual register classes will result in a zoo > of constraints for 8-bit, 16-bit, 32-bit registers. > >> in gcc-4.5, i've added a new class for each register to reg_class, >> REG_CLASS_NAMES and REG_CLASS_CONTENTS, made a need constrainst for >> each register using its class and it worked as expected. >> >> i tried to do the same in gcc-4.7 and i got: >> internal compiler error: in find_costs_and_classes, at ira-costs.c:1704. > > You will have to debug the compiler proper. > > Notice that hooks like HARD_REGNO_MODE_OK put additional restrictions on > registers/mode combinations. > >> So i was wondering whether i did the wrong thing or just forgot to >> update some target hook. >> >> Thanks, >> Ilya. > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Constrainst for individual registers 2012-01-25 6:56 ` Ilya Lesokhin @ 2012-01-26 16:24 ` Georg-Johann Lay 0 siblings, 0 replies; 4+ messages in thread From: Georg-Johann Lay @ 2012-01-26 16:24 UTC (permalink / raw) To: Ilya Lesokhin; +Cc: gcc-help Ilya Lesokhin schrieb: > Hi, > I've used your suggestion of "Specifying Registers for Local > Variables" and found out that code it generates gives better results > than my method. > > Unfortunately, a recent there on the subject: > http://gcc.gnu.org/ml/gcc/2012-01/msg00305.html > > got me worried, so I would like to hear what you (or anyone familiar > with the subjet) know about the status of implementation of "Local > register Variables" in the AVR backend in gcc-4.5.3 and if it's better > in newer gcc's. > > Specifically, I would like to know if you believe the following code > is safe (assuming _mul16x16_32 is implemented correctly): > > DWord_t mul16x16_32(uint16_t x, uint16_t y)__attribute__((always_inline)); > DWord_t mul16x16_32(uint16_t x, uint16_t y) > { > register uint16_t r24_25 asm ("r24") = x; > register uint16_t r22_23 asm ("r22") = y; > > register uint16_t r30_31 asm ("r30"); > register uint16_t r20_21 asm ("r20"); > > asm (" call _mul16x16_32" "\n\t" > : "=&r" (r20_21), "=&r" (r30_31) > : "r" (r24_25), "r" (r22_23) > : "r0", "r1", "cc" > ); > > DWord_t Result; > Result.High = r20_21; > Result.Low = r30_31; > return Result; > } From my understanding of the matter anf from the manual that should word. I don't understand the eary-clobber but it won't hurt here. But for similar code I saw ICE in fwprop, presumably because it failed to handle the additional register mess together with incoming function parameters depending on context of the call site. As you have fun backporting changes then and when, you might want to backport the widening multiply patches from PR49687. You don't need all that fancy combinations, the quinta essentia is umulhisi3 pattern/insn that performs the same operation as yours but without inline assembler needed, of course, and different interface. Your code then looked like DWord_t mul16x16_32(uint16_t x, uint16_t y) { uint32_t result = (uint32_t) x * y; ... The stuff in 4.7 works by mapping the insns to libgcc calls. As the insns explicitly model the register footprint of the libcall, special predicates are used to keep insn combine from propagating hard registers into (zero_)extend insns. Otherwise, combine fails to synthesize the pattern in some cases, i.e. if the "draft" footprint of mulsi3 overlaps the propagated hard reg. See comment at respective predicates. As umulhisi3 is a standard pattern and the tree optimizers handle widening multiply, umulhisi3 should work reasonabe even without that complexity. But I observed the general part having problems if one operand is an integer that fits in 16 bits. Johann > Thank, > Ilya. > > On 10/24/11, Georg-Johann Lay <avr@de> wrote: > >>>Hi, >>>I'm doing some modifections to the avr backend to suit my needs. >>> >>>I would like to add new constrainst for individual registers to use in >>>inline assembly blocks and i was wondering what is the correct way of >>>doing this? >> >>Not on topic: You can have a look at GCC's "Specifying Registers for >>Local Variables" feature: >>http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html#Local-Reg-Vars >> >>For example, this enables you to interface non-ABI assembler functions >>with C code without patching the compiler. >> >>Moreover, introducing individual register classes will result in a zoo >>of constraints for 8-bit, 16-bit, 32-bit registers. >> >>>in gcc-4.5, i've added a new class for each register to reg_class, >>>REG_CLASS_NAMES and REG_CLASS_CONTENTS, made a need constrainst for >>>each register using its class and it worked as expected. >>> >>>i tried to do the same in gcc-4.7 and i got: >>>internal compiler error: in find_costs_and_classes, at ira-costs.c:1704. >> >>You will have to debug the compiler proper. >> >>Notice that hooks like HARD_REGNO_MODE_OK put additional restrictions on >>registers/mode combinations. >> >>>So i was wondering whether i did the wrong thing or just forgot to >>>update some target hook. >>> >>>Thanks, >>>Ilya. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-01-26 1:52 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-24 8:09 Constrainst for individual registers איליה לסוחין 2011-10-24 19:41 ` Georg-Johann Lay 2012-01-25 6:56 ` Ilya Lesokhin 2012-01-26 16:24 ` Georg-Johann Lay
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).