[AVR] Cherry-pick 17 upstream AVR backend fixes into the Rust LLVM fork #66

dylanmckay · 2020-06-23T12:42:28Z

Related issue: rust-lang/rust#44052.
Related comment: rust-lang/rust#44052 (comment)

All of these commits have been cherry-picked directly from LLVM master. There was only one merge conflict whilst cherry-picking - with d7209133454dec385cda5bd3646342d211b43526 due to an LLVM API change. It was trivial to resolve and the cherry-picked does not differ in any meaningful way from upstream LLVM.

All 17 of these commits are required for correctness, although most of the commits are fixes for miscompilations rather than internal compiler errors. In other words, only about four of the commits here are required to get LLVM core compiling without a compiler error, but most the other 14 are required so that the AVR doesn't just crash.

All of the commits cherry-picked here have been committed to LLVM master in the last 6 months, corresponding to the release date of LLVM that Rust currently uses. When Rust updates its LLVM branch to the future LLVM 11.0 branch, none of these cherry-picks will be required because they will come automatically from upstream LLVM. LLVM 11.0 is scheduled to release in September this year.

Once these commits have been cherry-picks and rust-lang/rust#73270 is merged, the avr-rust/blink program can be successfully compiled and ran.

A number of multiplication instructions (muls, mulsu, fmul, fmuls, fmulsu) had the wrong register class for an operand. This resulted in the wrong register being used for the instruction. Example: target datalayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8" target triple = "avr-atmel-none" define i16 @sliceAppend(i16, i16, i16, i16, i16, i16) addrspace(1) { %d = mul i16 %0, %5 ret i16 %d } The first instruction would be muls r24, r31 before this patch. The r31 should have been r15 if you look at the intermediate forms during instruction selection / register allocation, but the generated instruction uses r31. After this patch, an extra movw is inserted to get %5 in range for muls. To make sure this bug is fixed everywhere, I checked all instructions and found that most multiplication instructions suffered from this bug, which I have fixed with this patch. No other instructions appear to be affected. Differential Revision: https://reviews.llvm.org/D74281

Adjusting by 2 breaks DWARF output. With this fix, programs start to compile and produce valid DWARF output. Differential Revision: https://reviews.llvm.org/D74213

Summary: LDRdPtr expanded from LDWRdPtr shouldn't define its second operand(SrcReg). The second operand is its source register. Add -verify-machineinstrs into command line of testcases can trigger this error. Reviewers: dylanmckay Reviewed By: dylanmckay Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75437

Found by the LLVM MemorySanitizer tests when switching AVR to a default backend. ELFArch must be initialized before the call to initializeSubtargetDependencies(). The uninitialized read would occur deep within TableGen'd code.

…target The initialization order was not correct. These bugs were discovered by valgrind. They appear to work fine in practice but this patch should unblock switching the AVR backend on by default as now a standard AVR llc invocation runs without memory errors. The AVRISelLowering constructor would run before the subtarget boolean fields were initialized to false. Now, the initialization order is correct.

nikic · 2020-06-23T13:07:01Z

llvm/CMakeLists.txt

@@ -289,6 +289,7 @@ set(LLVM_ALL_TARGETS
  AArch64
  AMDGPU
  ARM
+  AVR


I'd drop this, to keep target lists in sync with LLVM 10.

Good call, and rust-lang/master currently assumes AVR is an experimental backend so it is consistent there too.

I have dropped that commit (specifically cd16bb3c821) from the PR.

In the past, AVR functions were only lowered with interrupt-specific machine code if the function was defined with the "avr-interrupt" or "avr-signal" calling conventions. This patch modifies the backend so that if the function does not have a special calling convention, but does have an "interrupt" attribute, that function is interpreted as a function with interrupts. This also extracts the "is this function an interrupt" logic from several disparate places in the backend into one AVRMachineFunctionInfo attribute. Bug found by Wilhelm Meier.

The avr-libc provides *divmodqi4, *divmodhi4, and *divmodsi4 functions, but does not provide a *divmoddi4. Instead it provides regular *divdi3 and *moddi3 functions. Note that avr-libc doesn't support *divti3 or *modti3 for 128-bit integer manipulation. Source: https://github.com/gcc-mirror/gcc/blob/releases/gcc-5.4.0/libgcc/config/avr/lib1funcs.S Differential Revision: https://reviews.llvm.org/D78437

Previously, the AVR backend would put functions in .progmem.data. This is probably a regression from when functions still lived in address space 0. With this change, only global constants are placed in .progmem.data. This is not complete: avr-gcc additionally respects -fdata-sections for progmem global constants, which LLVM doesn't yet do. But fixing that is a bit more complicated (and I believe other backends such as RISC-V might also have similar issues). Differential Revision: https://reviews.llvm.org/D78212

Summary: On XMEGA, I/O address space is same as data address space - there is no 0x20 offset, because CPU General Purpose Registers are not mapped in data address space. From https://en.wikipedia.org/wiki/AVR_microcontrollers > In the XMEGA variant, the working register file is not mapped into the data address space; as such, it is not possible to treat any of the XMEGA's working registers as though they were SRAM. Instead, the I/O registers are mapped into the data address space starting at the very beginning of the address space. Reviewers: dylanmckay Reviewed By: dylanmckay Subscribers: hiraditya, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77207 Patch by Vlastimil Labsky.

@LemonBoy

Summary: Handle the emission of `R_AVR_6` ELF relocation type. Reviewers: dylanmckay Reviewed By: dylanmckay Subscribers: hiraditya, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78721 Patch by @LemonBoy https://reviews.llvm.org/p/LemonBoy/

This patch fixes a bug in stack save/restore code. Because the frame pointer was saved/restored manually (not by marking it as clobbered) the StackSize variable was not updated accordingly. Most code still worked, but code that tried to load a parameter passed on the stack did not. This commit fixes this by marking the frame pointer as a callee-clobbered register. This will let it be saved without any effort in prolog/epilog code and will make sure the correct address is calculated for loading parameters that are passed on the stack. This approach is used by most other targets (such as X86, AArch64 and RISC-V). Differential Revision: https://reviews.llvm.org/D78579

@bar

An instruction like this will need to allocate some stack space for the last parameter: %x = call addrspace(1) i16 @bar(i64 undef, i64 undef, i16 undef, i16 0) This worked fine when passing an actual value (in this case 0). However, when passing undef, no value was pushed to the stack and therefore no push instructions were created. This caused an unbalanced stack leading to interesting results. This commit fixes that by replacing the push logic with a regular stack adjustment and stack-relative load/stores. This is less efficient but at least it correctly compiles the code. I can think of a few improvements in the future: * The stack should have been adjusted in the function prologue when there are no allocas in the function. * Many (if not most) stack adjustments can be replaced by pushing/popping the values directly. Exactly like the previous code attempted but didn't do correctly. * Small stack adjustments can be done more efficiently with a few push/pop instructions (pushing/popping bogus values), both for code size and for speed. All in all, as long as there are no allocas in the function I think that it is almost always more efficient to emit regular push/pop instructions. This is however left for future optimizations. Differential Revision: https://reviews.llvm.org/D78581

@foo

Code like the following: define i32 @foo(i32 %a, i1 zeroext %b) addrspace(1) { entry: %conv = zext i1 %b to i32 %add = add nsw i32 %conv, %a ret i32 %add } Would compile to the following (incorrect) code: foo: mov r18, r20 clr r19 add r22, r18 adc r23, r19 sbci r24, 0 sbci r25, 0 ret Those sbci instructions are clearly wrong, they should have been adc instructions. This commit improves codegen to use adc instead: foo: mov r18, r20 clr r19 ldi r20, 0 ldi r21, 0 add r22, r18 adc r23, r19 adc r24, r20 adc r25, r21 ret This code is not optimal (it could be just 5 instructions instead of the current 9) but at least it doesn't miscompile. Differential Revision: https://reviews.llvm.org/D78439

I'm not entirely sure why this was ever needed, but when I remove both adjustments all tests still pass. This fixes a bug where a long branch (using the `jmp` instead of the `rjmp` instruction) was incorrectly adjusted by 2 because it jumps to an absolute address instead of a PC-relative address. I could have added AVR::fixup_call to the list of exceptions, but it seemed more sensible to me to just remove this code. Differential Revision: https://reviews.llvm.org/D78459

@fun

Summary: The previous version relied on the standard calling convention using std::reverse() to try to force the AVR ABI. But this only works for simple cases, it fails for example with aggregate types. This patch rewrites the calling convention with custom C++ code, that implements the ABI defined in https://gcc.gnu.org/wiki/avr-gcc. To do that it adds a few 16-bit pseudo registers for unaligned argument passing, such as R24R23. For example this function: define void @fun({ i8, i16 } %a) will pass %a.0 in R22 and %a.1 in R24R23. There are no instructions that can use these pseudo registers, so a new register class, DREGSMOVW, is defined to make them apart. Also the ArgCC_AVR_BUILTIN_DIV is no longer necessary, as it is identical to the C++ behavior (actually the clobber list is more strict for __div* functions, but that is currently unimplemented). Reviewers: dylanmckay Subscribers: Gaelan, Sh4rK, indirect, jwagen, efriedma, dsprenkels, hiraditya, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68524 Patch by Rodrigo Rivas Costa.

…e-with-picks, r=cuviper [AVR] Update the rust-lang/llvm-project submodule to include AVR fixes recently merged This PR updates rustc's LLVM submodule to include new AVR-specific fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch. All of these cherry-picked commits exist in upstream LLVM and were cherry-picked into Rust's LLVM fork in commit 6c040dd86ed. Relates to rust-lang/llvm-project#66 ``` |- 6c040dd86ed Merge pull request rust-lang#66 from dylanmckay/avr-pick-upstream-llvm-fixes |- 12dfdd3aed7 [AVR] Rewrite the function calling convention. |- 118ac53f12b [AVR] Don't adjust for instruction size |- bc27c282e13 [AVR] Fix miscompilation of zext + add |- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior |- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer |- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup |- 93ee4da19cf [AVR] Fix I/O instructions on XMEGA |- 962c2415ffb [AVR] Do not place functions in .progmem.data |- 65b8b170aef [AVR] Do not use divmod calls for bigger integers |- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal |- handlers too |- cc4286349b4 [AVR] Respect the 'interrupt' function attribute |- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget |- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch |- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr |- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values |- 6dfc55ba53b [AVR] Use correct register class for mul instructions ``` These changes include both correctness fixes and LLVM assertion error fixes. Once all of these commits have been cherry-picked, all of the LLVM plumbing for rust-lang/master to compile the AVR blink program will be in place. Once this commit is merged, only PR rust-lang#73270 will be blocking successful compilation and emission of the AVR LED blink program.

…with-picks, r=cuviper [AVR] Update the rust-lang/llvm-project submodule to include AVR fixes recently merged This PR updates rustc's LLVM submodule to include new AVR-specific fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch. All of these cherry-picked commits exist in upstream LLVM and were cherry-picked into Rust's LLVM fork in commit 6c040dd86ed. Relates to rust-lang/llvm-project#66 ``` |- 6c040dd86ed Merge pull request rust-lang#66 from dylanmckay/avr-pick-upstream-llvm-fixes |- 12dfdd3aed7 [AVR] Rewrite the function calling convention. |- 118ac53f12b [AVR] Don't adjust for instruction size |- bc27c282e13 [AVR] Fix miscompilation of zext + add |- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior |- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer |- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup |- 93ee4da19cf [AVR] Fix I/O instructions on XMEGA |- 962c2415ffb [AVR] Do not place functions in .progmem.data |- 65b8b170aef [AVR] Do not use divmod calls for bigger integers |- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal |- handlers too |- cc4286349b4 [AVR] Respect the 'interrupt' function attribute |- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget |- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch |- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr |- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values |- 6dfc55ba53b [AVR] Use correct register class for mul instructions ``` These changes include both correctness fixes and LLVM assertion error fixes. Once all of these commits have been cherry-picked, all of the LLVM plumbing for rust-lang/master to compile the AVR blink program will be in place. Once this commit is merged, only PR rust-lang#73270 will be blocking successful compilation and emission of the AVR LED blink program.

…uences When using a custom mutator (e.g. thrift mutator, similar to LPM) that calls back into libfuzzer's mutations via `LLVMFuzzerMutate`, the mutation sequences needed to achieve new coverage can get prohibitively large. Printing these large sequences has two downsides: 1) It makes the logs hard to understand for a human. 2) The performance cost slows down fuzzing. In this patch I change the `PrintMutationSequence` function to take a max number of entries, to achieve this goal. I also update `PrintStatusForNewUnit` to default to printing only 10 entries, in the default verbosity level (1), requiring the user to set verbosity to 2 if they want the full mutation sequence. For our use case, turning off verbosity is not an option, as that would also disable `PrintStats()` which is very useful for infrastructure that analyzes the logs in realtime. I imagine most users of libfuzzer always want those logs in the default. I built a fuzzer locally with this patch applied to libfuzzer. When running with the default verbosity, I see logs like this: rust-lang#65 NEW cov: 4799 ft: 10443 corp: 41/1447Kb lim: 64000 exec/s: 1 rss: 575Mb L: 28658/62542 MS: 196 Custom-CrossOver-ChangeBit-EraseBytes-ChangeBit-ChangeBit-ChangeBit-CrossOver-ChangeBit-CrossOver- DE: "\xff\xff\xff\x0e"-"\xfe\xff\xff\x7f"-"\xfe\xff\xff\x7f"-"\x17\x00\x00\x00\x00\x00\x00\x00"-"\x00\x00\x00\xf9"-"\xff\xff\xff\xff"-"\xfa\xff\xff\xff"-"\xf7\xff\xff\xff"-"@\xff\xff\xff\xff\xff\xff\xff"-"E\x00"- rust-lang#67 NEW cov: 4810 ft: 10462 corp: 42/1486Kb lim: 64000 exec/s: 1 rss: 577Mb L: 39823/62542 MS: 135 Custom-CopyPart-ShuffleBytes-ShuffleBytes-ChangeBit-ChangeBinInt-EraseBytes-ChangeBit-ChangeBinInt-ChangeBit- DE: "\x01\x00\x00\x00\x00\x00\x01\xf1"-"\x00\x00\x00\x07"-"\x00\x0d"-"\xfd\xff\xff\xff"-"\xfe\xff\xff\xf4"-"\xe3\xff\xff\xff"-"\xff\xff\xff\xf1"-"\xea\xff\xff\xff"-"\x00\x00\x00\xfd"-"\x01\x00\x00\x05"- Staring hard at the logs it's clear that the cap of 10 is applied. When running with verbosity level 2, the logs look like the below: rust-lang#66 NEW cov: 4700 ft: 10188 corp: 37/1186Kb lim: 64000 exec/s: 2 rss: 509Mb L: 47616/61231 MS: 520 Custom-CopyPart-ChangeBinInt-ChangeBit-ChangeByte-EraseBytes-PersAutoDict-CopyPart-ShuffleBytes-ChangeBit-ShuffleBytes-CopyPart-EraseBytes-CopyPart-ChangeBinInt-CopyPart-ChangeByte-ShuffleBytes-ChangeBinInt-ShuffleBytes-ChangeBit-CMP-ShuffleBytes-ChangeBit-CrossOver-ChangeBinInt-ChangeByte-ShuffleBytes-CrossOver-EraseBytes-ChangeBinInt-InsertRepeatedBytes-PersAutoDict-InsertRepeatedBytes-InsertRepeatedBytes-CrossOver-ChangeByte-ShuffleBytes-CopyPart-ShuffleBytes-CopyPart-CrossOver-ChangeBit-ShuffleBytes-CrossOver-PersAutoDict-ChangeByte-ChangeBit-ShuffleBytes-CrossOver-ChangeByte-EraseBytes-CopyPart-ChangeBinInt-PersAutoDict-CrossOver-ShuffleBytes-CrossOver-CrossOver-EraseBytes-CrossOver-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-ChangeByte-EraseBytes-ShuffleBytes-ShuffleBytes-ChangeBit-EraseBytes-ChangeBinInt-ChangeBit-ChangeBinInt-CopyPart-EraseBytes-PersAutoDict-EraseBytes-CopyPart-ChangeBinInt-ChangeByte-CrossOver-ChangeBinInt-ShuffleBytes-PersAutoDict-PersAutoDict-ChangeBinInt-CopyPart-ChangeBinInt-CrossOver-ChangeBit-ChangeBinInt-CopyPart-ChangeByte-ChangeBit-CopyPart-CrossOver-ChangeByte-ChangeBit-ChangeByte-ShuffleBytes-CMP-ChangeBit-CopyPart-ChangeBit-ChangeByte-ChangeBinInt-PersAutoDict-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBit-ChangeBinInt-ChangeBinInt-PersAutoDict-ChangeBinInt-ChangeBinInt-ChangeByte-CopyPart-ShuffleBytes-ChangeByte-ChangeBit-ChangeByte-ChangeByte-EraseBytes-CrossOver-ChangeByte-ChangeByte-EraseBytes-EraseBytes-InsertRepeatedBytes-ShuffleBytes-CopyPart-CopyPart-ChangeBit-ShuffleBytes-PersAutoDict-ShuffleBytes-ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ChangeByte-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBit-EraseBytes-CopyPart-ChangeByte-CrossOver-EraseBytes-CrossOver-ChangeByte-ShuffleBytes-ChangeByte-ChangeBinInt-CrossOver-ChangeByte-InsertRepeatedBytes-InsertByte-ShuffleBytes-PersAutoDict-ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ShuffleBytes-CopyPart-ShuffleBytes-EraseBytes-ShuffleBytes-ShuffleBytes-CrossOver-ChangeBinInt-CopyPart-CopyPart-CopyPart-EraseBytes-EraseBytes-ChangeByte-ChangeBinInt-ShuffleBytes-CMP-InsertByte-EraseBytes-ShuffleBytes-CopyPart-ChangeBit-CrossOver-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-EraseBytes-ChangeByte-ChangeBinInt-ChangeBit-ChangeBit-ChangeByte-ShuffleBytes-PersAutoDict-PersAutoDict-CMP-ChangeBit-ShuffleBytes-PersAutoDict-ChangeBinInt-EraseBytes-EraseBytes-ShuffleBytes-ChangeByte-ShuffleBytes-ChangeBit-EraseBytes-CMP-ShuffleBytes-ChangeByte-ChangeBinInt-EraseBytes-ChangeBinInt-ChangeByte-EraseBytes-ChangeByte-CrossOver-ShuffleBytes-EraseBytes-EraseBytes-ShuffleBytes-ChangeBit-EraseBytes-CopyPart-ShuffleBytes-ShuffleBytes-CrossOver-CopyPart-ChangeBinInt-ShuffleBytes-CrossOver-InsertByte-InsertByte-ChangeBinInt-ChangeBinInt-CopyPart-EraseBytes-ShuffleBytes-ChangeBit-ChangeBit-EraseBytes-ChangeByte-ChangeByte-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBinInt-ShuffleBytes-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-ShuffleBytes-CrossOver-EraseBytes-CopyPart-CopyPart-CopyPart-ChangeBit-ShuffleBytes-ChangeByte-EraseBytes-ChangeByte-InsertRepeatedBytes-InsertByte-InsertRepeatedBytes-PersAutoDict-EraseBytes-ShuffleBytes-ChangeByte-ShuffleBytes-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeBit-CrossOver-CrossOver-ShuffleBytes-CrossOver-CopyPart-CrossOver-CrossOver-CopyPart-ChangeByte-ChangeByte-CrossOver-ChangeBit-ChangeBinInt-EraseBytes-ShuffleBytes-EraseBytes-CMP-PersAutoDict-PersAutoDict-InsertByte-ChangeBit-ChangeByte-CopyPart-CrossOver-ChangeByte-ChangeBit-ChangeByte-CopyPart-ChangeBinInt-EraseBytes-CrossOver-ChangeBit-CrossOver-PersAutoDict-CrossOver-ChangeByte-CrossOver-ChangeByte-ChangeByte-CrossOver-ShuffleBytes-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-ChangeBinInt-ChangeBinInt-ChangeBinInt-ShuffleBytes-CrossOver-ChangeBinInt-ShuffleBytes-ChangeBit-PersAutoDict-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeByte-CrossOver-ChangeBit-CopyPart-ChangeBit-ChangeBit-CopyPart-ChangeByte-PersAutoDict-ChangeBit-ShuffleBytes-ChangeByte-ChangeBit-CrossOver-ChangeByte-CrossOver-ChangeByte-CrossOver-ChangeBit-ChangeByte-ChangeBinInt-PersAutoDict-CopyPart-ChangeBinInt-ChangeBit-CrossOver-ChangeBit-PersAutoDict-ShuffleBytes-EraseBytes-CrossOver-ChangeByte-ChangeBinInt-ShuffleBytes-ChangeBinInt-InsertRepeatedBytes-PersAutoDict-CrossOver-ChangeByte-Custom-PersAutoDict-CopyPart-CopyPart-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeBit-ShuffleBytes-CrossOver-CMP-ChangeByte-CopyPart-ShuffleBytes-CopyPart-CopyPart-CrossOver-CrossOver-CrossOver-ShuffleBytes-ChangeByte-ChangeBinInt-ChangeBit-ChangeBit-ChangeBit-ChangeByte-EraseBytes-ChangeByte-ChangeBit-ChangeByte-ChangeByte-CopyPart-PersAutoDict-ChangeBinInt-PersAutoDict-PersAutoDict-PersAutoDict-CopyPart-CopyPart-CrossOver-ChangeByte-ChangeBinInt-ShuffleBytes-ChangeBit-CopyPart-EraseBytes-CopyPart-CopyPart-CrossOver-ChangeByte-EraseBytes-ShuffleBytes-ChangeByte-CopyPart-EraseBytes-CopyPart-CrossOver-ChangeBinInt-ChangeBinInt-InsertByte-ChangeBinInt-ChangeBit-ChangeByte-CopyPart-ChangeByte-EraseBytes-ChangeByte-ChangeBit-ChangeByte-ShuffleBytes-CopyPart-ChangeBinInt-EraseBytes-CrossOver-ChangeBit-ChangeBit-CrossOver-EraseBytes-ChangeBinInt-CopyPart-CopyPart-ChangeBinInt-ChangeBit-EraseBytes-InsertRepeatedBytes-EraseBytes-ChangeBit-CrossOver-CrossOver-EraseBytes-EraseBytes-ChangeByte-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeBit-ChangeByte-EraseBytes-ChangeBit-ChangeByte-ChangeByte-CrossOver-CopyPart-EraseBytes-ChangeByte-EraseBytes-ChangeByte-ShuffleBytes-ShuffleBytes-ChangeByte-CopyPart-ChangeByte-ChangeByte-ChangeBit-CopyPart-ChangeBit-ChangeBinInt-CopyPart-ShuffleBytes-ChangeBit-ChangeBinInt-ChangeBit-EraseBytes-CMP-CrossOver-CopyPart-ChangeBinInt-CrossOver-CrossOver-CopyPart-CrossOver-CrossOver-InsertByte-InsertByte-CopyPart-Custom- DE: "warn"-"\x00\x00\x00\x80"-"\xfe\xff\xff\xfb"-"\xff\xff"-"\x10\x00\x00\x00"-"\xfe\xff\xff\xff"-"\xff\xff\xff\xf6"-"U\x01\x00\x00\x00\x00\x00\x00"-"\xd9\xff\xff\xff"-"\xfe\xff\xff\xea"-"\xf0\xff\xff\xff"-"\xfc\xff\xff\xff"-"warn"-"\xff\xff\xff\xff"-"\xfe\xff\xff\xfb"-"\x00\x00\x00\x80"-"\xfe\xff\xff\xf1"-"\xfe\xff\xff\xea"-"\x00\x00\x00\x00\x00\x00\x012"-"\xe2\x00"-"\xfb\xff\xff\xff"-"\x00\x00\x00\x00"-"\xe9\xff\xff\xff"-"\xff\xff"-"\x00\x00\x00\x80"-"\x01\x00\x04\xc9"-"\xf0\xff\xff\xff"-"\xf9\xff\xff\xff"-"\xff\xff\xff\xff\xff\xff\xff\x12"-"\xe2\x00"-"\xfe\xff\xff\xff"-"\xfe\xff\xff\xea"-"\xff\xff\xff\xff"-"\xf4\xff\xff\xff"-"\xe9\xff\xff\xff"-"\xf1\xff\xff\xff"- rust-lang#48 NEW cov: 4502 ft: 9151 corp: 27/750Kb lim: 64000 exec/s: 2 rss: 458Mb L: 50772/50772 MS: 259 ChangeByte-ShuffleBytes-ChangeBinInt-ChangeByte-ChangeByte-ChangeByte-ChangeByte-ChangeBit-CopyPart-CrossOver-CopyPart-ChangeByte-CrossOver-CopyPart-ChangeBit-ChangeByte-EraseBytes-ChangeByte-CopyPart-CopyPart-CopyPart-ChangeBit-EraseBytes-ChangeBinInt-CrossOver-CopyPart-CrossOver-CopyPart-ChangeBit-ChangeByte-ChangeBit-InsertByte-CrossOver-InsertRepeatedBytes-InsertRepeatedBytes-InsertRepeatedBytes-ChangeBinInt-EraseBytes-InsertRepeatedBytes-InsertByte-ChangeBit-ShuffleBytes-ChangeBit-ChangeBit-CopyPart-ChangeBit-ChangeByte-CrossOver-ChangeBinInt-ChangeByte-CrossOver-CMP-ChangeByte-CrossOver-ChangeByte-ShuffleBytes-ShuffleBytes-ChangeByte-ChangeBinInt-CopyPart-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-InsertByte-ChangeBit-CopyPart-ChangeBinInt-ChangeByte-CrossOver-ChangeBit-EraseBytes-CopyPart-ChangeBinInt-ChangeBit-ChangeBit-ChangeByte-CopyPart-ChangeBinInt-CrossOver-PersAutoDict-ChangeByte-ChangeBit-ChangeByte-ChangeBinInt-ChangeBinInt-EraseBytes-CopyPart-CopyPart-ChangeByte-ChangeByte-EraseBytes-PersAutoDict-CopyPart-ChangeByte-ChangeByte-EraseBytes-CrossOver-CopyPart-CopyPart-CopyPart-ChangeByte-ChangeBit-CMP-CopyPart-ChangeBinInt-ChangeBinInt-CrossOver-ChangeBit-ChangeBit-EraseBytes-ChangeByte-ShuffleBytes-ChangeBit-ChangeBinInt-CMP-InsertRepeatedBytes-CopyPart-Custom-ChangeByte-CrossOver-EraseBytes-ChangeBit-CopyPart-CrossOver-CMP-ShuffleBytes-EraseBytes-CrossOver-PersAutoDict-ChangeByte-CrossOver-CopyPart-CrossOver-CrossOver-ShuffleBytes-ChangeBinInt-CrossOver-ChangeBinInt-ShuffleBytes-PersAutoDict-ChangeByte-EraseBytes-ChangeBit-CrossOver-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-EraseBytes-InsertByte-InsertRepeatedBytes-InsertByte-InsertByte-ChangeByte-ChangeBinInt-ChangeBit-CrossOver-ChangeByte-CrossOver-EraseBytes-ChangeByte-ShuffleBytes-ChangeBit-ChangeBit-ShuffleBytes-CopyPart-ChangeByte-PersAutoDict-ChangeBit-ChangeByte-InsertRepeatedBytes-CMP-CrossOver-ChangeByte-EraseBytes-ShuffleBytes-CrossOver-ShuffleBytes-ChangeBinInt-ChangeBinInt-CopyPart-PersAutoDict-ShuffleBytes-ChangeBit-CopyPart-ShuffleBytes-CopyPart-EraseBytes-ChangeByte-ChangeBit-ChangeBit-ChangeBinInt-ChangeByte-CopyPart-EraseBytes-ChangeBinInt-EraseBytes-EraseBytes-PersAutoDict-CMP-PersAutoDict-CrossOver-CrossOver-ChangeBit-CrossOver-PersAutoDict-CrossOver-CopyPart-ChangeByte-EraseBytes-ChangeByte-ShuffleBytes-ChangeByte-ChangeByte-CrossOver-ChangeBit-EraseBytes-ChangeByte-EraseBytes-ChangeBinInt-CrossOver-CrossOver-EraseBytes-ChangeBinInt-CrossOver-ChangeBit-ShuffleBytes-ChangeBit-ChangeByte-EraseBytes-ChangeBit-CrossOver-CrossOver-CrossOver-ChangeByte-ChangeBit-ShuffleBytes-ChangeBit-ChangeBit-EraseBytes-CrossOver-CrossOver-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-CopyPart-CrossOver-CopyPart-CrossOver-CrossOver-EraseBytes-EraseBytes-ShuffleBytes-InsertRepeatedBytes-ChangeBit-CopyPart-Custom- DE: "\xfe\xff\xff\xfc"-"\x00\x00\x00\x00"-"F\x00"-"\xf3\xff\xff\xff"-"St9exception"-"_\x00\x00\x00"-"\xf6\xff\xff\xff"-"\xfe\xff\xff\xff"-"\x00\x00\x00\x00"-"p\x02\x00\x00\x00\x00\x00\x00"-"\xfe\xff\xff\xfb"-"\xff\xff"-"\xff\xff\xff\xff"-"\x01\x00\x00\x07"-"\xfe\xff\xff\xfe"- These are prohibitively large and of limited value in the default case (when someone is running the fuzzer, not debugging it), in my opinion. Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D86658

66: Make yk build with `-Werror,-Wglobal-constructors`. r=jacob-hughes a=vext01 Co-authored-by: Edd Barrett <vext01@gmail.com>

aykevl and others added 5 commits June 24, 2020 00:26

[AVR] Don't adjust addresses by 2 for absolute values

96075fc

Adjusting by 2 breaks DWARF output. With this fix, programs start to compile and produce valid DWARF output. Differential Revision: https://reviews.llvm.org/D74213

dylanmckay mentioned this pull request Jun 23, 2020

RFC: Merging the avr-rust fork upstream rust-lang/rust#44052

Closed

nikic reviewed Jun 23, 2020

View reviewed changes

dylanmckay and others added 11 commits June 24, 2020 01:24

[AVR] Generalize the previous interrupt bugfix to signal handlers too

93a3b59

dylanmckay force-pushed the avr-pick-upstream-llvm-fixes branch from d720913 to 12dfdd3 Compare June 23, 2020 13:24

nikic merged commit 6c040dd into rust-lang:rustc/10.0-2020-05-05 Jun 23, 2020

dylanmckay mentioned this pull request Jun 23, 2020

[AVR] Update the rust-lang/llvm-project submodule to include AVR fixes recently merged rust-lang/rust#73658

Merged

vext01 added a commit to vext01/llvm-project that referenced this pull request May 4, 2023

Merge rust-lang#66

fd75496

66: Make yk build with `-Werror,-Wglobal-constructors`. r=jacob-hughes a=vext01 Co-authored-by: Edd Barrett <vext01@gmail.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[AVR] Cherry-pick 17 upstream AVR backend fixes into the Rust LLVM fork #66

[AVR] Cherry-pick 17 upstream AVR backend fixes into the Rust LLVM fork #66

dylanmckay commented Jun 23, 2020

nikic Jun 23, 2020

dylanmckay Jun 23, 2020

@@ @@ -289,6 +289,7 @@ set(LLVM_ALL_TARGETS @@
                 AArch64
                 AMDGPU
                 ARM
+                AVR

[AVR] Cherry-pick 17 upstream AVR backend fixes into the Rust LLVM fork #66

[AVR] Cherry-pick 17 upstream AVR backend fixes into the Rust LLVM fork #66

Conversation

dylanmckay commented Jun 23, 2020

nikic Jun 23, 2020

Choose a reason for hiding this comment

dylanmckay Jun 23, 2020

Choose a reason for hiding this comment