[LLVMdev] PIC16 backend for llvm 2.5

Duncan Sands baldrick at free.fr
Fri Jan 16 01:03:34 PST 2009


Hi Sanjiv,

> Well the magnitude of the task is not small.
> ExpandIntegerOperand() calls LowerOperation() to allow targets to handle
> illegal operands. So we will need to change the interface of
> LowerOperation() to pass an extra argument called Results, which is an
> array of SDValue. Targets will push the result values in this array and
> then we can replace values in ExpandIntegerOperand(). Very much like
> what CustomLowerResults() and ReplaceNodeResults() are doing currently.
> 
> The problem is that do we want to change calls to LowerOperation() in
> LegalizeDAG as well? I think probably that is the right approach to go
> in the longer term. But currently I suggest that "Results" be the last
> argument to LowerOperation() which is defaulted to NULL. That way
> LegalizeDAG and all targets will continue to work the current way, plus
> targets like ours that want to use the last argument (i.e. "Results")
> can use them in ExapndIntegerOperand().

do you need this for operation legalization (LegalizeDAG) as well as
type legalization?  If not, then you can introduce a new method like
ReplaceNodeResults for custom type legalization of operands (or just
use ReplaceNodeResults for this too - I don't immediately see any
reason why not), and have it call LowerOperation by default.  Actually,
if you also want this for LegalizeDAG too, you can introduce a new method
which is only called in places that need it; everywhere else can still
use LowerOperation (of course in the long term there should be just one
method, but this way you can do things incrementally).  I don't much
like the idea of having Results be NULL.  I'd rather the interface was
uniform, and have any tricks be in the body of the method.

Ciao,

Duncan.



More information about the llvm-dev mailing list