I plan to match this soon-ish as this is essentially just a revert.

Commented regarding tests and nits. Could you update docs/CommandGuide/llvm-objcopy.rst as well?

LGTM but make sure it passes recently updated lit tests.

E.g., vmin generation for ARM target

E.g., vmax generation for ARM target

• Addressed a review comment.

Though this situation is valid.

Any comments from the llvm-objcopy community?

unique_ptr<int> -> NonDefaultConstructible

You could use a noisy type here to test that only the appropriate operations were executed

In D67698#1675370, @lenary wrote:

We discussed this in the RISC-V meeting on 19 Sep 2019.

• Pros: GCC for RISC-V and LLVM for ARM and AArch64 seem to do the same. It can help in situations with particularly bad register pressure requirements.
• Cons: It can make debugging a lot harder, though this seems not to be an issue in GDB for RISC-V.
  
  I think we don't want to have yet another configuration flag to control this.
  
  It would be good to see some performance comparison, but I realise you may not be able to release internal benchmarks, and we have no public benchmarking system for RISC-V.

• feedback

In D67038#1675878, @wyjw wrote:

I do not have commit access. Could someone please help me with the commit?

Thanks!

LGTM

I've reworked this -- finally -- as zturner suggested. I'll be posting it as a bunch of individual commits, so i'm abandoning this one.

In the description of the git commit:

will re-submit as individual patches.

I made 8548 an alias in clang to e500, because e500 is recognized in llvm as a CPU, so gets us the feature list and, more importantly, the instruction scheduler.

In D67583#1675714, @hhb wrote:

My theory now is that your python has a different implementation of get_python_lib(). After all we should not guess what python would do. I'm making a change.
If you still interested in testing that, you can fix the path in a.py...

Under http://eel.is/c++draft/cpp#cond-7.sentence-2, the identifier __has_include can't appear anywhere other than in the context of an #if, #elif, #iifdef, or #ifndef. That's what we should be checking for and diagnosing here (and we should produce an ExtWarn rather than a Warning for this case, because such code is ill-formed, and accepting it at all is a language extension compared to the C++ rules). We should apply the same behavior to __has_cpp_attribute, to which the same rule applies.

I do not have commit access. Could someone please help me with the commit?

I fixed our problem with r372366.

Sweet.

In D67785#1675848, @echristo wrote:

The x86isellowering change is great, see if you can't remove some of the branches before committing?

Committed as r372366.

• Tighten up the test case.

In D67693#1675449, @jakehehrlich wrote:

To be clear though, we have a test ensuring that -B is ignored, correct?

The x86isellowering change is great, see if you can't remove some of the branches before committing?

@sunfish I believe you originally added the GlobalAddress patterns so I wanted to check in with you before removing them. Do you know whether they can ever be used? If so I will add tests for them instead, but I'm not sure I've ever seen a GlobalAddress offset.