See D42593, I don't think it's good to ignore security flags like this.

I agree with Joerg, I don't think we should be ignoring these kinds of security flags (even though we already ignore -fstack-check).

Example of test failure: https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-f29-pr-pipeline/51/artifact/package-tests/logs/FAIL_str_regression-tests.log

LGTM.

LGTM.

Updated patch to fix non-standalone builds. There is more refactoring
that could be done, but this at least restores functionality to before
r353268.

Address comments.

LGTM.

LGTM.

LGTM.

LGTM.

OK, LGTM.

LGTM.

LGTM.

In D57406#1377725, @xiaobai wrote:

I wrote a patch similar to this in LLDB, so I'll chime in a bit.

@mgorny: This doesn't actually *break* the build per se. This change just means you need to do a bit more work to be able to test the lld you just built. Some things that could be done to improve the situation:

• Users who want to test lld should specify LLVM_BUILD_MAIN_SRC_DIR (and possibly LLVM_LIT_EXE) manually.

In D57406#1377708, @compnerd wrote:

This doesn't break the build, we check that the path exists, and find_program will not error out. You can still specify LLVM_LIT_EXE to specify the lit.py to use. Is that not sufficient for your needs?

The clang patch was merged a few months ago. LGTM.

I made a similar change to clang: https://reviews.llvm.org/rL346732, and I think this is the right direction to go.

Address review comments.

Add TableGen patterns for loads of pointer types.

LGTM.

Fix spelling.

In D55914#1366633, @dsanders wrote:

In D55914#1364207, @tstellar wrote:

You can actually use iPTR types in patterns already, but the GlobalISel backend converts it to a scalar integer when generating the ISel code.

Hmm, I'm not keen on munging the types together. I'd prefer to generate appropriate checks.

Just to give some background on iPTR:
DAGISel patterns are a bit inconsistent on their usage of iPTR. iPTR is just a scalar integer with a dynamically assigned size and as a result the patterns have scalar integers in patterns that should have pointers and pointers in patterns that should have scalar integers. This is mentioned in the iPTR definition (llvm/CodeGen/MachineValueType.h):

// An int value the size of the pointer of the current
// target to any address space. This must only be used internal to
// tblgen. Other than for overloading, we treat iPTRAny the same as iPTR.

and TargetLoweringBase::getPointerTy():

MVT TargetLoweringBase::getPointerTy(const DataLayout &DL, uint32_t AS = 0) const {
  return MVT::getIntegerVT(DL.getPointerSizeInBits(AS));
}

It doesn't matter much for DAGISel as pointers aren't really a concept it deals with but GlobalISel considers pointers and scalars to be different things and as a result iPTR has some context specific behaviour. For ptypeN operands on instructions (e.g. the pointer operand of a G_LOAD) it's a pointer and GlobalISelEmitter emits a different predicate (OperandMatcher::addTypeCheckPredicate()), while all other contexts convert it to a scalar integer like DAGISel did (but only if there's only one choice after applying type constraints, if there's more it will reject the pattern). If you trace it back, it's CodeGenInstruction::isOperandAPointer() that triggers that special behaviour which is looking for TypedOperand.IsPointer in the InOperandList for the instruction.

What opcodes do you need to cover? If they're generic opcodes, does changing typeN to ptypeN have the desired effect? If they're more general things like G_ADD, then this wasn't an issue for AArch64 and our out-of-tree targets. We could potentially add predicates for pointer-sized scalars so that we emit the right checks.

You can actually use iPTR types in patterns already, but the GlobalISel backend converts it to a scalar integer when generating the ISel code.

In D55914#1364175, @arsenm wrote:

Would it be difficult to add ptr types in tablegen's version of MVT, which the table gen backend converts as appropriate?

In D55914#1337199, @arsenm wrote:

Aren't we going to need a way to represent this in tablegen eventually?

LGTM.

LGTM.

In D53554#1350691, @chandlerc wrote:

In D53554#1329303, @tstellar wrote:

+ I'm still a little confused by the layering of TTI. I tried to move the
implementation out of TargetTransformInfoImplBase and into BasicTTI, but
that breaks the NoTTIImpl class.

For NoTTIImpl you can just return false, or return false except for integer types that DataLayout thinks are legal.

The difference between NoTTIImpl and the "basic" layer inside CodeGen is that the basic layer can reach into common target-independent parts of the code generator (like the type legalization tables) to compute plausible answers, where NoTTIImpl is supposed to only return trivially evident information based on the IR-level input. Further, there is *no* quality bar for NoTTIImpl -- it's more for target-indepndent testing, and not supposed to have any quality per-se.

I don't have this in my notes, but my recollection from the GitHub round-table at the Dev Meeting was that the preference was to not have any files to the root directory. I think step 1 would be to discuss the general issue of files in the root directory on llvm-devel.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

I will push it, since you confirmed it fixes the build.

In D51748#1338824, @hans wrote:

Maybe add a release note for out-of-tree users of this? We had to adjust our clang plugin build files in Chromium for example.

In D55965#1338809, @SquallATF wrote:

Module libraries are always treated as LIBRARY targets. via https://cmake.org/cmake/help/v3.0/command/install.html, but D51748 marked as RUNTIME targets when build with mingw

This has been superseded by D55965.

Remove unnecessary #include