[llvm-dev] [RFC] Implementing a general purpose 64-bit target (RISC-V 64-bit) with i64 as the only legal integer type

[Bruce Hoult via llvm-dev]

li a0,-1
srli a0,a0,0x20

... works for me. Both 16 bit instructions. And similar for any other
sequence of 0s in hi bits followed by 1s in lo.

And indeed, yes, the divu() as a whole would be better as:

slli a0,a0,0x20
slli a1,a1,0x20
srli a0,a0,0x20
srli a1,a1,0x20
divu a0,a0,a1
sext.w a0,a0
ret

(scheduled for a dual-issue machine. Would be different for a machine with
macro-op fusion)

Really looking forward to 64 bit in upstream!

On Thu, Oct 4, 2018 at 12:21 AM, Alex Bradbury <asb at lowrisc.org> wrote:

> On Thu, 4 Oct 2018 at 08:03, Bruce Hoult via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Now rebased to ToT, as of now.
> >
> > All that mess in divu is the same as is generated from:
> >
> > long foo(){
> >     return 0x00000000ffffffffl;
> > }
> >
> > 0000000000000000 <foo>:
> >    0: 00000537          lui a0,0x0
> >    4: 0005059b          sext.w a1,a0
> >    8: 1582                slli a1,a1,0x20
> >    a: 357d                addiw a0,a0,-1
> >    c: 1502                slli a0,a0,0x20
> >    e: 9101                srli a0,a0,0x20
> >   10: 8d4d                or a0,a0,a1
> >   12: 8082                ret
> >
> > For sure that's not the best way to generate that constant!
>
> Definitely not. That pattern was a placeholder just to produce
> something correct. The list of changes described in the RFC describes
> the work implemented to end up with mostly reasonable-looking codegen.
> I'm hoping to start posting these to phabricator later today.
>
> That constant takes 3 instructions with smarter 64-bit immediate
> materialisation. For zext i32 -> i64 you'd prefer to perform two
> shifts, unless you can CSE the mask.
>
> Best,
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181004/5dcc9524/attachment.html>