[llvm-dev] [RFC] Implementing a general purpose 64-bit target (RISC-V 64-bit) with i64 as the only legal integer type (original) (raw)
Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 4 00:21:02 PDT 2018
- Previous message: [llvm-dev] [RFC] Implementing a general purpose 64-bit target (RISC-V 64-bit) with i64 as the only legal integer type
- Next message: [llvm-dev] [RFC] Implementing a general purpose 64-bit target (RISC-V 64-bit) with i64 as the only legal integer type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 : 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
- Previous message: [llvm-dev] [RFC] Implementing a general purpose 64-bit target (RISC-V 64-bit) with i64 as the only legal integer type
- Next message: [llvm-dev] [RFC] Implementing a general purpose 64-bit target (RISC-V 64-bit) with i64 as the only legal integer type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]