Thanks for submitting this! Please add tests for -g and all variants of -gline-tables-only.

Thanks @rsuderman. Updated.

In D144083#4218819, @sgraenitz wrote:

This was due to my change to use a target flag to represent the thumb bit. Obviously, these are target-specific and ObjectLinkingLayer has to account for that. Relanding now with the fix.

Thanks, and the issue is fixed in your reland.

• cleanup changes for review comments

• Remove the test pass
• Add a tranform op instead
• Add a comment for strides when creating the subview
• Add a test for non-1 strides (only for vector.transfer_write, @nicolasvasilache let me know if you want more)
• Report failures with notifyMatchFailure

Remove FIXME: The test case seems to be fully vectorizing the function, rather than half-vectorizing it as the comment states.

Want to add a release note for this as well?

LGTM!

Thanks, guys!
@dmgreen could you please clarify, did you run benchmarks with PredictableSelectIsExpensive only or did you use 75% prediction rate threshold as well?

wrong button..

Update SLP vectorizer test case

Thanks!

In D146812#4219705, @jhuber6 wrote:

LG as long as we can fix it later once the bot picks it up.

Remove test rename diff

Another minor tweak to clang/test/CodeGen/PowerPC/ppc64le-varargs-f128.c.

Use a tail agnostic policy if we're inserting at a suffix

Adding a test showing that using .option arch in inline assembly doesn't affect ELF attributes nor set the EF_RISCV_RVC ELF flag would be nice. The latter can also be tested for assembly files.

Patch updated per review.

In D146733#4219448, @erichkeane wrote:

LGTM! Let me know if you need someone to commit this for you, and include "Name To Use <EmailAddr>"

Is this the first of ten vendors types? Do I need a flag to enable the PowerPC vector type or does it also work on other architectures?

LGTM with test nit

Thanks for the review!

Sure

LG as long as we can fix it later once the bot picks it up.

In case folks are worried about this debug content:
this patch will have a short life span, once we see the dump from the BOT, we can revert it.

Thanks for adding this flang.

Rebase and ping.

First and foremost, thank you for keeping this up to date and iterating upon it while the .option arch proposal was under review in the asm manual. I think we're basically almost there.

Looks good to me with some notes:

• LLVMs verifier seems to work differently by checking that ALL landing pads and resume instructions use consistent types: https://github.com/llvm/llvm-project/blob/b2c48559c882fd558f91e471c4d23ea7b0c6e718/llvm/lib/IR/Verifier.cpp#L4196 This seems contrary to what the langref says however which is confusing to me.
• Could you rebase the patch? Recent changes have landed that has turned all these tests to opaque pointers.

• Removed the opt-pipeline.ll test.

I will add tests.

lgtm, thanks.

Hi Samuel,

In D144651#4219633, @fdeazeve wrote:

In D144651#4219340, @aaron.ballman wrote:

The build lab's lldb builders are all green, and greendragon's standalone build is also green. Could this be a problem with incremental builds being in a bad state somehow?

I don't think so, as I can reliably reproduce this on my machine. I believe the _contents_ of the SDK headers affect what is fed to Clang, and therefore we see the crash with some SDKs but not others.

LGTM

@bd1976llvm Can you file an issue for this: https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches

(pardon the interruption, some drive-by comments :))

In D146720#4219568, @aeubanks wrote:

could we not put the full pipeline as a test and just check that relevant passes run?

Thank you for the work!

Rebasing on test commit. My applogies for noise, I still get confused with arc sometimes.

In D144651#4219340, @aaron.ballman wrote:

In D144651#4217750, @john.brawn wrote:

Unfortunately I still can't reproduce this even using exactly the same cmake command as you gave. Looking at above cmake log some possible causes of difference are:

• I'm doing this on an M1 macbook with host triple arm64-apple-darwin21.6.0 but the host triple on that bot is x86_64-apple-darwin20.6.0
• I'm using python 3.9, bot is using python 3.10
• I'm doing a build from clean whereas the bot is doing an incremental build

Also if I try to run the simpler reproducer you give then I get the error

error: expression failed to parse:
error: Header search couldn't locate module Cocoa

I'm now on holiday, I won't be able to get back to this until 2023-04-03.

The build lab's lldb builders are all green, and greendragon's standalone build is also green. Could this be a problem with incremental builds being in a bad state somehow?

Reintroduced bug commit refernces. Sorry for the noise, but I still sometimes get confused with arc.

Reverted accidentally included changes.

Wow, thanks for finding that and for the quick work!

format

Revision of tests

Still LGTM

Landing this because my build has been broken for the past few hours.

I've put up https://reviews.llvm.org/D146813 to move the loop invariant GEP reassociation into LICM, which should allow us to drop the LoopInfo dependency from InstCombine.

Fixed debug build.

LGTM w/minor comments.

could we not put the full pipeline as a test and just check that relevant passes run?

(I think the most obvious/easy example is, if I recall correctly, line zero is used for merged function calls)

Rebase. Tweak ImplicitOps calculation to avoid misleading variable name.

when the test detects the error, can we dump out all the arrays data1, data2, data3, and sum . and then break ...