Hi, I'm building a backend for a 64-bit target based on the existing Mips 32 one and I've come up against a problem with 32-bit loads. If you load a 32-bit value into a register this needs extending to fit into a native 64-bit register. The initial selection DAG acomplishes this using an any_extend node, which isn't handled later on by any instruction selector and thus LLVM can't produce the target code. Now I could just handle an any_extend load, however if you load a 8-bit or 16-bit value the initial selection DAG uses a sign_extend (or zero_extend) node to turn it into a native 64-bit type and I would like the same behaviour for 32-bit loads. So my questions are: 1) What causes the Initial selection DAG code to choose an any_extend over a sign_extend (or zero_extend)? 2) What does any_extend actually signify? Presumably this indicates that either a sign extend or zero extend will suffice. Cheers, Greg
Hi Greg,> 1) What causes the Initial selection DAG code to choose an any_extend > over a sign_extend (or zero_extend)?because it is more efficient: the backend gets more choice in how to do it, and at the same time it tells the optimizers that the extra bits contain rubbish, which gives them more freedom to reason.> 2) What does any_extend actually signify? Presumably this indicates > that either a sign extend or zero extend will suffice.Yes, or anything else. Ciao, Duncan.
Duncan Sands wrote:> Hi Greg, > >> 1) What causes the Initial selection DAG code to choose an any_extend >> over a sign_extend (or zero_extend)? > > because it is more efficient: the backend gets more choice in how to do > it, and at the same time it tells the optimizers that the extra bits > contain rubbish, which gives them more freedom to reason.Makes sense, though I was wondering why it would choose to sign_extend an 8-bit or 16-bit value, but any_extend a 32-bit value (These are all signed values).> >> 2) What does any_extend actually signify? Presumably this indicates >> that either a sign extend or zero extend will suffice. > > Yes, or anything else. >Anyway thanks for the info, I'll just implement an any_extend load (The original MIPS backend doesn't seem to have any, which is why I was wary of doing it in the first place). Cheers, Greg