Rebase against submitted changes.

In D99381#2651896, @mcgrathr wrote:

I don't think this is warranted. There should not be any references to such things when building for Fuchsia.
This looks like it's intended to satisfy one reference in dead code in hwasan_interceptors.cpp.
I think the right solution is just to refactor the hwasan code so that the dead code is not compiled for Fuchsia at all.

In D91334#2628496, @mstorsjo wrote:

In D91334#2621320, @phosek wrote:

I don't think this is an issue with this change, it's an issue on our side.

Did you guys manage to sort this one out, or is there still some lingering issue potentially related to this?

LGTM pending a few more comments. Should also give some time to let others respond if they have feedback.

Hi, it seems that unroll_double.ll is failing on our clang builders (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8852671182559485616):

Hi, I believe this patch may have indirectly led to a failure in our two-stage clang builder (https://luci-milo.appspot.com/p/fuchsia/builders/prod/clang-linux-x64/b8853033259975286848?):

Will submit this now to fix up the CI builders, but we can revert this later if any major changes are needed.

One thing that just occurred to me: do we also perhaps want to hide this behind a flag? Right now it's being added to various default optimization pipelines, so some users might be surprised if they suddenly see their lookup tables change (either compiler or user generated). Do we want to make this something more opt-in, or is the layout itself not necessarily a concern to most users?

In D96945#2615019, @leonardchan wrote:

In D96945#2614982, @aqjune wrote:

Yep, I reverted this patch. Could you post the commandline options that is used to build LLVM?
There was a similar failure reported (D95026) which is due to an existing bug in InstructionSimplify; maybe I can check whether its prospective fix resolves this issue as well.

Thanks for the followup. Can do. Let me see if I can minimize the reproducer/reduce the number of cmake flags needed for ease first since the two-stage build has dependencies on libxml2 and zlib.

While I'm doing that, if you already have a fix, what I can do is patch it locally and get back to you on if it also fixes the issues we see.

In D96945#2614982, @aqjune wrote:

Yep, I reverted this patch. Could you post the commandline options that is used to build LLVM?
There was a similar failure reported (D95026) which is due to an existing bug in InstructionSimplify; maybe I can check whether its prospective fix resolves this issue as well.

A bisect seems to show this patch causing the test failures we see on our two-stage clang builders (https://luci-milo.appspot.com/p/fuchsia/builders/prod/clang-linux-x64/b8853364937280028160?):

@dexonsmith @mehdi_amini Would you be the right folks to add for reviews on ValueMapper?

In D97978#2607908, @phosek wrote:

Is it feasible to cover this by a test?

Hi, I suspect thispatch might be causing the failure we're seeing in our non-mac builders (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8853941557626730880?):

In D96780#2574007, @dmgreen wrote:

I've committed c141c6551be64f220b71786d24e98f6de906e6de in an attempt to fix the similar problem I was seeing here. Please let me know if it helps or doesn't in the Fuchsia build.

It looks like you have everything setup for running on the new PM, but it doesn't look like the pass is added anywhere in the new PM pipeline. Unfortunately, I don't *think* there's anything in the new PM that acts as a "default pipeline that gets added to all other pipelines" similar to PassManagerBuilder::populateModulePassManager, so we'll need to manually include this somewhere in PassBuilder::buildO0DefaultPipeline and PassBuilder::buildPerModuleDefaultPipeline.

In D96170#2567026, @rjmccall wrote:

In D96170#2566975, @leonardchan wrote:

In D96170#2561432, @rjmccall wrote:

I've never patched the bitcode reader/writer before, I think, but from similar patches I've seen, this look good to me. Is there any sort of registration you're supposed to do of the new code?

Hmm. By registration, do you mean making cmake aware of the new test? I don't *think* there's anything else I may need to change. I mainly just copied similar logic from how the other constant codes are handled.

Adding @rnk who may have more familiarity.

Some of the other serializers using bitcode require some of the codes to be registered, either as abbreviations or just for incidental reasons. If there's nothing like that for similar record codes, though, it's probably not a thing for BC.

In D96170#2561432, @rjmccall wrote:

I've never patched the bitcode reader/writer before, I think, but from similar patches I've seen, this look good to me. Is there any sort of registration you're supposed to do of the new code?

In D95960#2566681, @pcc wrote:

I think you will need to s/needsRelocation/needsDynamicRelocation/g throughout the rest of the codebase.

*ping* Any comments for this patch? I believe these are mostly mechanical changes that were left out of the original DSOLocalEquivalent patch.

Updated to remove needsStaticRelocation.

Hi. I suspect this patch might be causing this test failure we're seeing on our builders (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8855749711840653472?):

Hi. This test seems to be failing on our clang builder (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-arm64/b8855886813666955488?):

LGTM. Confirmed on our end this fixes our issue. Thanks for addressing this!

In D93839#2523703, @curdeius wrote:

That's definitely an unintended behaviour. Please file a bug and possibly mark it as release blocker for LLVM 12. Either a fix will be there soon, or we'll revert.

FYI, simple reproduce:

verifyFormat("#include <stdint.h>\n"
             "namespace rep {}",
             Style);

The problem doesn't happen with #include "stdint.h".

Hi. Up until this point, we've noticed that this patch can produce different formatted files depending on amount of whitespace. For example, given (A):

Almost there! Just a few more comments on my end.

Hi. It seems this commit is causing this failure on our aarch64 bulder (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-arm64/b8857452110716658368):

Also, this probably isn't very important, but just as a heads up: if we were to depend on the environment component in the triple as the flag for selecting which multilib to use, then the multilib would be stored in a directory containing that environment.

In D93668#2492081, @phosek wrote:

I agree that if we want to allow selecting C++ ABI only, a flag like -fc++abi= with some additional checks to disallow invalid combinations is better. The question is whether we want to allow that in the first place? The motivation behind this change is to support generating code that's ABI compatible with the code generated by GCC. That could be expressed using the target triple (one idea is to use *-*-fuchsia-gnu), which would cover both C++ ABI as well as other aspects of the ABI (for example it could also disable SafeStack/ShadowCallStack) so developers don't need to concern themselves with all the details of the ABI, which could evolve over time expanding the set of flags you'd need to pass to the compiler to generate code that's ABI compatible with GCC.

In D91466#2395297, @pcc wrote:

How does Zircon handle tagged addresses in syscalls? Are they handled equivalently to Linux's tagged address ABI?

Locally I'm able to build and run the bringup.arm64 config (that is launch the shell and run some commands).

Looking good. Just a few more comments on my end.

In D93668#2482986, @phosek wrote:

I'd prefer to use the target triple rather than introducing a custom flag.

With dedicated flags, you might eventually end up in a similar situation as D85802, that is in the extreme case you might end up with -f[no-]fuchsia-c++-abi, -f[no-]webassembly-c++-abi, etc. which is not any better than -fc++-abi=.

With target triple, I can imagine using either <arch>-unknown-fuchsia-itanium or <arch>-unknown-fuchsia-gnu, where the former would mean targeting Fuchsia with Itanium C++ ABI while the latter would mean using GCC compatible ABI (which would imply Itanium C++ ABI). Both of these are already used by MinGW for the same purpose so there's a precedent and we don't need to invent anything new.

Ok this time I remembered the email. Unsure why the bug isn't automatically closed though.

Committed in 155fca3cae275562e626d3e4fbfac70b4b75d2e7. (Sorry, I forgot to change the author email in the commit)

Sorry. I accidentally missed this in my emails. Will commit these.