Skip to content

Conversation

@calc84maniac
Copy link

Inlined memmove was generating a comparison pseudo-instruction using the input destination pointer register directly, which could end up being an invalid register such as IY, generating an sbc hl, iy instruction.

I moved the comparison into the memmove pseudo-instruction itself to ensure it always uses sbc hl, de, and also optimized the LDDR path to use the subtraction result to add BC-1 to DE prior to adding it back into HL.

I also managed to ensure the BC, DE, HL registers are carried directly into the LDIR/LDDR paths, though I'm not 100% sure if what I did was valid (I allocated virtual registers to pass them into the blocks, then replaced all usages of those virtual registers with the physical registers). LLVM didn't yell at me though, unlike with some other approaches I tried.

Example code output before this fix:

        ld      hl, (iy + 5)
        ld      bc, 5
        call    __imulu
        push    hl
        pop     de
        ld      hl, _vars
        add     hl, de
        ld      (ix - 14), hl
        lea     de, iy
        or      a, a
        sbc     hl, iy
        jr      c, BB2_5
        ld      hl, (ix - 14)
        ld      iy, 5
        lea     bc, iy
        ldir
        jr      BB2_6
BB2_5:
        ld      hl, (ix - 14)
        ld      iy, 5
        lea     bc, iy
        add     hl, bc
        dec     hl
        ex      de, hl
        add     hl, bc
        dec     hl
        ex      de, hl
        lddr
BB2_6:
        ld      de, (ix - 14)
        ld      hl, (ix - 11)
        lea     bc, iy
        ldir

And after:

        ld      hl, (iy + 5)
        ld      bc, 5
        call    __imulu
        push    hl
        pop     de
        ld      hl, _vars
        add     hl, de
        lea     de, iy
        push    hl
        pop     iy
        or      a, a
        sbc     hl, de
        jr      c, BB2_5
        add     hl, de
        ldir
        jr      BB2_6
BB2_5:
        ex      de, hl
        add     hl, bc
        dec     hl
        ex      de, hl
        add     hl, de
        lddr
BB2_6:
        lea     de, iy
        ld      hl, (ix - 11)
        ld      bc, 5
        ldir

brad0 and others added 30 commits September 19, 2022 08:51
(cherry picked from commit 3eca0b3)
…PR57692)

Callee save registers must be preserved, so -fzero-call-used-regs
should not be zeroing them. The previous implementation only did
not zero callee save registers that were saved&restored inside the
function, but we need preserve all of them.

Fixes llvm#57692.

Differential Revision: https://reviews.llvm.org/D133946

(cherry picked from commit b430980)
If libcxxabi is not included CMake will error out:

Cannot find target libcxxabi-SHARED

I ran into this doing the 15.0.0 release

Differential Revision: https://reviews.llvm.org/D133475
…ockfree

In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.

After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).

However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.

This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.

Fixes llvm#57440

Differential Revision: https://reviews.llvm.org/D133377

(cherry picked from commit f1a601f)
The test requires the AArch64 backend, so move it to the right subdir.
Epilogue vectorization uses isScalarAfterVectorization to check if
widened versions for inductions need to be generated and bails out in
those cases.

At the moment, there are scenarios where isScalarAfterVectorization
returns true but VPWidenPointerInduction::onlyScalarsGenerated would
return false, causing widening.

This can lead to widened phis with incorrect start values being created
in the epilogue vector body.

This patch addresses the issue by storing the cost-model decision in
VPWidenPointerInductionRecipe and restoring the behavior before 151c144.
This effectively reverts 151c144, but the long-term fix is to properly
support widened inductions during epilogue vectorization

Fixes llvm#57712.
(cherry picked from commit 59351fe)
…e release

In LLVM 15, we added the deprecation markup for unary_function and
binary_function for >= C++11, and we also removed it for >= C++17.
While this is in accordance with the Standard, it's also a bit quick
for our users, since there was no release in which the classes were
marked as deprecated before their removal.

We noticed widespread breakage due to this, and after months of trying
to fix downstream failures, I am coming to the conclusion that users
will be better served if we give them one release where unary_function
is deprecated but still provided even in >= C++17.

Differential Revision: https://reviews.llvm.org/D134473
This solves llvm#57664

Reviewed By: sameerds

Differential Revision: https://reviews.llvm.org/D134019

(cherry picked from commit c941d92)
This avoids deprecation warning:
```
warning: definition of implicit copy assignment operator for 'AddrInfo'
is deprecated because it has a user-declared copy constructor
[-Wdeprecated-copy]
```

This fixes llvm#57229

(cherry picked from commit 252cea0)
The unittests are already included in check-polly, so check-all was
running them twice.  Running them twice causes a race on the output
files, which led to intermittent failures on the reverse-iteration
buildbot.

(cherry picked from commit 2c29268)
For RVC, GNU assembler and LLVM integrated assembler add c.nop followed by a
sequence of 4-byte nops. Even if remove % 4 == 0, we have to split one 4-byte
nop and therefore need to write the code sequence, otherwise we create an
incorrect c.unimp.

(cherry picked from commit 78084d9)
…rs' is deactivated

'misc-const-correctness' previously considered arrays as 'Values' independent of the type of the elements.
This is inconsistent with the configuration of the check to disable treating pointers as values.
This patch rectifies this inconsistency.

Fixes llvm#56749

Reviewed By: njames93

Differential Revision: https://reviews.llvm.org/D130793

(cherry picked from commit e66345d)
Improve the documentation for 'misc-const-correctness' to:

- include better examples
- improve the english
- fix links to other checks that were broken due to the directory-layout changes
- mention the limitation that the check does not run on `C` code.

Addresses llvm#56749, llvm#56958

Reviewed By: njames93

Differential Revision: https://reviews.llvm.org/D132244

(cherry picked from commit b5b7503)
If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.

In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.

Fixes llvm#57710.

Differential Revision: https://reviews.llvm.org/D134591

(cherry picked from commit afec0f0)
When checking the RHS of fdiv, we should set the SignBitOnly flag,
because a negative zero can become -Inf, which is ordered less
than zero.

Fixes llvm#58046.

Differential Revision: https://reviews.llvm.org/D134876
Fixes a null dereference in some diagnostic issuing code.

Closes llvm#57370
Closes llvm#58028

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D134885

(cherry picked from commit 9415aad)
Add test showing miscompilation during epilogue vectorization with SVE.

(cherry picked from commit 1716700)
The dependent code has been changed quite a lot since 151c144 which
b73d2c8 effectively reverts. Now we run into a case where lowering
didn't expect/support the behavior pre 151c144 any longer.

Update the code dealing with scalable pointer inductions to also check
for uniformity in combination with isScalarAfterVectorization. This
should ensure scalable pointer inductions are handled properly during
epilogue vectorization.

Fixes llvm#57912.

(cherry picked from commit 2c692d8)
(cherry picked from commit dd428a5)
Currently, clang does not emit debuginfo for the switch stmt
case value if it is an enum value. For example,
  $ cat test.c
  enum { AA = 1, BB = 2 };
  int func1(int a) {
    switch(a) {
    case AA: return 10;
    case BB: return 11;
    default: break;
    }
    return 0;
  }
  $ llvm-dwarfdump test.o | grep AA
  $
Note that gcc does emit debuginfo for the same test case.

This patch added such a support with similar implementation
to CodeGenFunction::EmitDeclRefExprDbgValue(). With this patch,
  $ clang -g -c test.c
  $ llvm-dwarfdump test.o | grep AA
                  DW_AT_name    ("AA")
  $

Differential Revision: https://reviews.llvm.org/D134705

(cherry picked from commit 75be048)
add LLVM_PREFER_STATIC_ZSTD (default TRUE) cmake config flag
(compression test seems to fail for shared zstd on windows, note that zstd multithread is by default disabled in the static build so it may be a hidden variable)
propagate variable zstd_DIR in LLVMConfig.cmake.in
fix llvm-config CMakeLists.txt behavior for absolute libs windows
get zstd lib name

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D132870

(cherry picked from commit c0b4f24)
removes LLVM_PREFER_STATIC_ZSTD in favor of using a LLVM_USE_STATIC_ZSTD

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D133222

(cherry picked from commit fc1da04)
adriweb and others added 28 commits May 12, 2025 13:34
python3 ../llvm/utils/update_llc_test_checks.py --llc-binary ./bin/llc ../llvm/test/CodeGen/Z80/*.ll
Idk how to squash with commits inbetween
Not needed on some compilers/toolchain, but doesn't hurt anyway.
More modern LLVM versions have it as well.
If needed, we could run something like this in powershell:
Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID, Size, FreeSpace
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.