Advertisement

Close

Thanks, this should now be just the NFC refactoring, with most clang-tidy/clang-format suggestions applied (I ignored the DWARF one for obvious reasons).

Advertisement

Close

Ping.

Advertisement

Close

Ping.

Thanks Amara. Committed with a beefed up comment as 5e3d9fcc3a88.

Added support for i386 (for the watch simulator). Mostly came for free but some slight issues around swiftself and CSRs.

Ping.

Ping.

Looks like a good change to me.

I think this looks reasonable. Preserving Darwin is probably the safest choice, though I don't know if we actually rely on it. If the description is actually the commit message make sure it's updated before committing because this patch does in fact change the Clang side too.

Ping.

Ping.

Fixed the issue in SelectionDAG too. Not quite identical there, but still fundamentally hinged on exactly where the check should be placed.

We've just discovered there are problems on the SDAG path too for guaranteed tail calls. I'll update the patch once I've got a fix ready.

Thanks, looks good to me.

Ping.

Ping.

I think this is fine.

Looks reasonable to me. If you were really keen you could probably write a MIR test (it complains loudly when an instruction has the wrong regclass), but in reality I think it's unlikely to matter. This isn't exactly a high-traffic part of the backend.

Thanks. I think it looks good too now.

Thanks. LGTM.

Just a rebase really (minor comment & doc changes). Also ping.

In this update:

I doubt it. because when I run test files separately they are passing. The issue occurs when I merge them in a single file.

Please tell me what I am missing now?

The two programs are identical, right? If so, you can put more than one RUN line in a single file to test it. Then use FileCheck --check-prefix=EXEC %s, EXEC: Hello World!.

Ping.

Looks sensible to me.

Spotted a couple of issues over the last week:

Thanks. I think this looks like the best fix we can do now.

We already seem to have shouldSignExtendTypeInLibCall (used in the actual ExpandLibCall this code gets to) and shouldExtendTypeInLibCall (used in another expander I didn't know about). Ideally that's where we'd fix this issue by getting the generic call lowerer to insert a zext (which may be folded again later, if it's a sound transformation). Unfortunately because we only have an i32 when the expansion happens I don't think that's possible.

Thanks Ahmed, committed as c93d50dd7168.

Ping.

• Updated documentation as requested.
• Changed CallSeq_start AArch64 operand so we don't reserve the stack space twice.

Of course, should have spotted that one.

Thanks for applying the suggested fixes. I think I'm happy with it now.

I think this looks good now, modulo Sjoerd's last comment.

Is there a check that this folding doesn't overrun a red-zone if it does exist? If not, fixing that could well lead to a more natural way to solve this (where the bounds being checked are just 0 if there's no red-zone).

1. Applied Kristof's FrameLowering suggestion.
2. Added IR-level tests for the attribute I'd forgotten about.

Thanks for the questions. I'm quite fuzzy on the Swift side of this I'm afraid, so take my replies with a pinch of salt.

Nice! So iOS will benefit outline atomics too.

Outline atomics were added with gcc 9.3.1 and turned on by default in gcc 10.1. Consequently most of distributions had libgcc with outline atomics already.

Also, even on Linux it seems Clang is inclined to link against libgcc rather than libclang by default (at least that's what my Debian one does). When did these functions get into libgcc? I'm worried that a significant proportion of users there will find themselves having to add extra command-line options (whether disabling this or forcing libclang) to produce binaries.

Sorry, ignore that. Wrong review.

Also, even on Linux it seems Clang is inclined to link against libgcc rather than libclang by default (at least that's what my Debian one does). When did these functions get into libgcc? I'm worried that a significant proportion of users there will find themselves having to add extra command-line options (whether disabling this or forcing libclang) to produce binaries.

As it stands this needs to be a platform-level change. The compiler-rt stuff may now compile outside Linux (thanks!), but the capability detection is still fundamentally Linux (and even glibc) only so nothing else would use it as intended.

Ping.

I think this looks reasonable now.

That's a nice improvement. Still LGTM.

I think this is a reasonable change, inline asm is pretty rare.

LGTM.

Looks fine to me except for one weird quirk that I don't think should be there.

To github.com:llvm/llvm-project.git

c54d827fdb12..c5978f42ec8e  main -> main

Ping.

Ping.

Thanks Gerolf. Committed: