[RFC] AEABI Divmod refactoring + 64-bit

Renato Golin renato.golin at linaro.org
Tue Jul 30 04:43:22 PDT 2013


On 30 July 2013 11:18, Tim Northover <t.p.northover at gmail.com> wrote:

> What about creating special ARMISD::SREM64 (etc) nodes to represent
> the operation during ReplaceNodeResults?


Now that you mention, that did cross my mind very briefly, but I thought I
could still fix it some other way, and then I lost it.

In the light of all my other attempts, this idea is looking good again, but
only insofar as the argument for it are "it has been done before" or "we
know it won't break surrounding type legalizations" type of things.



> They could take 4 i32
> operands as input and produce 2 i32s as output (All legit 32-bit
> operations, guv, honest! Wouldn't touch any of that 64-bit filth!).
> You could then feed the output of this node back to the type legalizer
> however it expects it (a build_pair op?).
>

Here's what I don't get. After I use ReplaceNodeResults to legalize SREM64,
when legalizing other operations that depend on those results,
GetExpandedInteger()
still won't find Lo/Hi. How do I get to communicate between custom type
lowering and expand type lowering?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130730/b18ff61b/attachment.html>


More information about the llvm-commits mailing list