[all-commits] [llvm/llvm-project] 13ca0c: [lld][WebAssembly] Align __heap_base
Ayke via All-commits
all-commits at lists.llvm.org
Sat Jul 24 05:03:43 PDT 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 13ca0c87edd026813ef7cbf3fbeb0efdb9c8bd3c
https://github.com/llvm/llvm-project/commit/13ca0c87edd026813ef7cbf3fbeb0efdb9c8bd3c
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
A lld/test/wasm/Inputs/stack-first.s
M lld/test/wasm/stack-first.test
M lld/wasm/Writer.cpp
Log Message:
-----------
[lld][WebAssembly] Align __heap_base
__heap_base was not aligned. In practice, it will often be aligned
simply because it follows the stack, but when the stack is placed at the
beginning (with the --stack-first option), the __heap_base might be
unaligned. It could even be byte-aligned.
At least wasi-libc appears to expect that __heap_base is aligned:
https://github.com/WebAssembly/wasi-libc/blob/659ff414560721b1660a19685110e484a081c3d4/dlmalloc/src/malloc.c#L5224
While WebAssembly itself does not appear to require any alignment for
memory accesses, it is sometimes required when sharing a pointer
externally. For example, WASI might expect alignment up to 8:
https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md#-timestamp-u64
This issue got introduced with the addition of the --stack-first flag:
https://reviews.llvm.org/D46141
I suspect the lack of alignment wasn't intentional here.
Differential Revision: https://reviews.llvm.org/D106499
Commit: feda08b70a9bbb55bbdd1b85a83d29f3ed41cf08
https://github.com/llvm/llvm-project/commit/feda08b70a9bbb55bbdd1b85a83d29f3ed41cf08
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
M llvm/lib/Target/AVR/AVRISelLowering.cpp
M llvm/test/CodeGen/AVR/call.ll
M llvm/test/CodeGen/AVR/dynalloca.ll
M llvm/test/CodeGen/AVR/varargs.ll
Log Message:
-----------
[AVR] Do not chain stores in call frame setup
Previously, AVRTargetLowering::LowerCall attempted to keep stack stores
in order with chains. Perhaps this worked in the past, but it does not
work now: it appears that the SelectionDAG legalization phase removes
these chains. Therefore, I've removed these chains entirely to match
X86 (which, similar to AVR, also prefers to use push instructions over
stack-relative stores to set up a call frame). With this change, all the
stack stores are in a somewhat reasonable order.
Differential Revision: https://reviews.llvm.org/D97853
Commit: 8544ce80f881a33a2c4c8e234709d136b52fa4d8
https://github.com/llvm/llvm-project/commit/8544ce80f881a33a2c4c8e234709d136b52fa4d8
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
M llvm/lib/Target/AVR/AVRInstrInfo.td
Log Message:
-----------
[AVR] Set R31R30 as clobbered after ADJCALLSTACKDOWN
In most cases, using R31R30 is fine because the call (which always
precedes ADJCALLSTACKDOWN) will clobber R31R30 anyway. However, in some
rare cases the register allocator might insert an instruction between
the call and the ADJCALLSTACKDOWN instruction and expect the register
pair to be live afterwards. I think this happens as a result of
rematerialization. Therefore, to fix this, the instruction needs to have
Defs set to R31R30.
Setting the Defs field does have the effect of making the instruction
look dead, which it certainly is not. This is fixed by setting
hasSideEffects to true.
Differential Revision: https://reviews.llvm.org/D97745
Commit: 431a9414655ba4825a46e6765ef50a0b4ef7e101
https://github.com/llvm/llvm-project/commit/431a9414655ba4825a46e6765ef50a0b4ef7e101
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
M llvm/lib/Target/AVR/AVRExpandPseudoInsts.cpp
M llvm/lib/Target/AVR/AVRInstrInfo.td
Log Message:
-----------
[AVR] Improve 8/16 bit atomic operations
There were some serious issues with atomic operations. This patch should
fix the biggest issues.
For details on the issue take a look at this Compiler Explorer sample:
https://godbolt.org/z/n3ndhn
Code:
void atomicadd(_Atomic char *val) {
*val += 5;
}
Output:
atomicadd:
movw r26, r24
ldi r24, 5 ; 'operand' register
in r0, 63
cli
ld r24, X ; load value
add r24, r26 ; value += X
st X, r24 ; store value back
out 63, r0
ret ; return the wrong value (in r24)
There are various problems with this.
- The value to add (5) is stored in r24. However, the value to add to
is loaded in the same register: r24.
- The `add` instruction adds half of the pointer to the loaded value,
instead of (attempting to) add the operand with value 5.
- The output value of the cmpxchg instruction (which is not used in
this code sample) is the new value with 5 added, not the old value.
The LangRef specifies that it has to be the old value, before the
operation.
This patch fixes the first two and leaves the third problem to be fixed
at a later date. I believe atomics were mostly broken before this patch,
with this patch they should become usable as long as you ignore the
output of the atomic operation. In particular it fixes the following
things:
- It sets the earlyclobber flag for the input ('$operand' operand) so
that the register allocator puts it in a different register than the
output value.
- It fixes a number of issues with the pseudo op expansion pass, for
example now it adds the $operand field instead of the pointer. This
fixes most machine instruction verifier issues (other flagged issues
are unrelated to atomics).
Differential Revision: https://reviews.llvm.org/D97127
Commit: 6aa9e746ebde6efd2479fa833d2d816d0a7bb353
https://github.com/llvm/llvm-project/commit/6aa9e746ebde6efd2479fa833d2d816d0a7bb353
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
M llvm/lib/Target/AVR/AVR.h
A llvm/lib/Target/AVR/AVRShiftExpand.cpp
M llvm/lib/Target/AVR/AVRTargetMachine.cpp
M llvm/lib/Target/AVR/CMakeLists.txt
A llvm/test/CodeGen/AVR/shift-expand.ll
Log Message:
-----------
[AVR] Expand large shifts early in IR
This patch makes sure shift instructions such as this one:
%result = shl i32 %n, %amount
are expanded just before the IR to SelectionDAG conversion to a loop so
that calls to non-existing library functions such as __ashlsi3 are
avoided. The generated code is currently pretty bad but there's a lot of
room for improvement: the shift itself can be done in just four
instructions.
Differential Revision: https://reviews.llvm.org/D96677
Commit: 41f905b211fc904d10f819618dcb62f90ba82c45
https://github.com/llvm/llvm-project/commit/41f905b211fc904d10f819618dcb62f90ba82c45
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
M llvm/lib/Target/AVR/AVRExpandPseudoInsts.cpp
M llvm/lib/Target/AVR/AVRInstrInfo.td
M llvm/test/CodeGen/AVR/rot.ll
Log Message:
-----------
[AVR] Fix rotate instructions
This patch fixes some issues with the RORB pseudo instruction.
- A minor issue in which the instructions were said to use the SREG,
which is not true.
- An issue with the BLD instruction, which did not have an output operand.
- A major issue in which invalid instructions were generated. The fix
also reduce RORB from 4 to 3 instructions, so it's also a small
optimization.
These issues were flagged by the machine verifier.
Differential Revision: https://reviews.llvm.org/D96957
Commit: 4d7f5c0a85cde0c144a424059e53079230ec2ea2
https://github.com/llvm/llvm-project/commit/4d7f5c0a85cde0c144a424059e53079230ec2ea2
Author: Ayke van Laethem <aykevanlaethem at gmail.com>
Date: 2021-07-24 (Sat, 24 Jul 2021)
Changed paths:
M llvm/lib/Target/AVR/AVRISelLowering.cpp
A llvm/test/CodeGen/AVR/intrinsics/named-reg-alloc.ll
A llvm/test/CodeGen/AVR/intrinsics/named-reg-special.ll
R llvm/test/CodeGen/AVR/intrinsics/read_register.ll
Log Message:
-----------
[AVR] Only support sp, r0 and r1 in llvm.read_register
Most other registers are allocatable and therefore cannot be used.
This issue was flagged by the machine verifier, because reading other
registers is considered reading from an undefined register.
Differential Revision: https://reviews.llvm.org/D96969
Compare: https://github.com/llvm/llvm-project/compare/b7a464989955...4d7f5c0a85cd
More information about the All-commits
mailing list