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: msp430 port


On 07/30/2013 05:24 PM, DJ Delorie wrote:
> Fixed.  Perhaps gen* could error on those?  I know they're ignored, I
> just keep forgetting that splits are special.
> 
> (alternately, why can't they be included in the matching logic?)

(Because pre-reload, pseudos don't have register classes, mostly)

>>> +(define_insn "*bic<mode>_cg"
>>> +  [(set (match_operand:QHI 0 "msp_nonimmediate_operand" "=rYs,m")
>>> +	(and:QHI (match_operand:QHI 1 "msp_general_operand" "0,0")
>>> +		 (match_operand 2 "msp430_inv_constgen_operator" "n,n")))]
>>> +  ""
>>> +  "@
>>> +   BIC%x0%B0\t#%I2, %0
>>> +   BIC%X0%B0\t#%I2, %0"
>>> +)
>>
>> This really should be an alternative of
>>
>>> +(define_insn "and<mode>3"
>>> +  [(set (match_operand:QHI 0 "msp_nonimmediate_operand" "=rYs,rm")
>>> +	(and:QHI (match_operand:QHI 1 "msp_nonimmediate_operand" "%0,0")
>>> +		 (match_operand:QHI 2 "msp_general_operand" "riYs,rmi")))
>>> +   (clobber (reg:CC CARRY))
>>> +   ]
>>> +  ""
>>> +  "@
>>> +   AND%x0%B0\t%2, %0
>>> +   AND%X0%B0\t%2, %0"
>>> +)
>>
>> ... this.
> 
> The first doesn't have a clobber, though...

Hmm.  Missed that.  So the only reason you'd care to include the bic
in the regular and pattern is if it were a smaller encoding than the
regular r/0/i alternative.

>> I suppose shrink-wrapping results in larger prologues and epilogues
>> in general?  Otherwise I'd suggest using simple_return here.
> 
> ../../gcc-trunkb/gcc/function.c: In function 'vec<edge_def*, va_heap, vl_ptr> convert_jumps_to_returns(basic_block_def*, bool, vec<edge_def*, va_heap, vl_ptr>)':
> ../../gcc-trunkb/gcc/function.c:5765: error: 'emit_use_return_register_into_block' was not declared in this scope
> ../../gcc-trunkb/gcc/function.c:5767: error: 'emit_return_into_block' was not declared in this scope
> ../../gcc-trunkb/gcc/function.c:5797: error: 'emit_use_return_register_into_block' was not declared in this scope
> ../../gcc-trunkb/gcc/function.c: In function 'basic_block_def* emit_return_for_exit(edge_def*, bool)':
> ../../gcc-trunkb/gcc/function.c:5839: error: 'emit_return_into_block' was not declared in this scope
> ../../gcc-trunkb/gcc/function.c: In function 'void thread_prologue_and_epilogue_insns()':
> ../../gcc-trunkb/gcc/function.c:6594: error: 'emit_return_into_block' was not declared in this scope
> ../../gcc-trunkb/gcc/function.c:6625: error: 'emit_return_into_block' was not declared in this scope

You need to implement the "return" pattern as well as "simple_return".
They don't actually have to be different, implementation-wise.  See
the i386 version, where both named patterns expand to the same insn.

>> That's because the insn is mis-defined.  Even with unspec_volatile, you must
>> respect the form of rtl.  Above, operand 1 is positioned as an input, which is
>> wrong.  It must be positioned as an output, e.g.
>>
>>   [(set (match_operand 0 "register_operand" "=r")
>>         (unspec_volatile [(match_operand 1 "immediate_operand" "i")]
>>                          UNS_POPM))]
>>   "POPM%B0\t%1, %0
> 
> operand 1 indicates *one* of the registers that is popped, but not all
> of them.  POPM pops a variable number of registers.  How do you
> specifiy that in RTL?

It depends on your requirements.  Is it strictly 1, 2, 4 registers?  In
which case it's easiest to use HI, SI, DImode with one output.

Is it odd, or large numbers of registers?  Do you need these patterns
before reload (e.g. as part of your block move expansion)?

If you only need them post-reload, follow the lead of the s390 port.
See the "load_multiple" and "store_multiple" expanders, and their
associated insns.  In this case, everything folds nicely down with
a match_parallel.

If you need them pre-reload, you'll have to use the more complicated
scheme used by the ARM port.  There, you have a set of patterns for
every distinct number of registers, since reload can't see through
a match_parallel in order to do replacement.

> It's not the stack register, it's the *stack*.  We know the stack is
> in the first 64k, but other objects may not be.  The MSP430X has a
> feature in silicon that, if a register 'happens' to be less than 64k,
> will truncate a (reg+int16) address to 64k, but if the register is
> already above 64k, no truncation occurs.  I.e. the 64k wrap depends on
> the *value* in the register, not the addressing mode or opcode
> encoding.
> 
> So, for example, if R6 has 0xffe0 and you use [R6+0x0100], you will
> get [0x00e0] not [0x100e0], but if R6 has 0x1ffe0 you get [0x200e0].

Oh my.  Ew.


r~


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