It is difficult remembering exactly what my thought process was way back when but the redzone calculation seems very likely...

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

In D77777#1975618, @hliao wrote:

In D77777#1975406, @tra wrote:

In D77777#1975178, @hliao wrote:

the 1st argument in llvm.nvvm.texsurf.hande.internal or the 2nd one in llvm.nvvm.texsurf.handle must be kept as an immediate or constant value, i.e. that global variable. However, optimizations will find common code in the following

if (cond) {
  %hnd = texsurf.handle.internal(@tex1);
} else {
  %hnd = texsurf.handle.internal(@tex2)
}
= use(%hnd)

and hoist or sink it into

if (cond) {
  %ptr = @tex1;
} else {
  %ptr = @tex2;
}
%hnd = texsurf.handle.intenal(%ptr);
= use(%hnd)

The backend cannot handle non immediate operand in texsurf.handle. The similar thing happens to read.register as well as it also assumes its argument is always an immediate value.

I wonder if we can use token types to represent the handle? https://reviews.llvm.org/D11861
@majnemer -- would this use case be suitable for the token type?

If we still could make PHI over token, it canont serve this purpose. Check llvm::canReplaceOperandWithVariable for operand for details.

LGTM

Please upload with full context.

LGTM

LGTM

LGTM

In D64141#1568924, @ThomasR wrote:

In D64141#1568896, @jmolloy wrote:

Most of this looks mechanical; I don't think the MVT changes should be contentious. However, the "is65536BitVector()" predicates are starting to get a bit unwieldy to read.

Does an out of tree target need these predicates? I feel they're sufficiently unreadable to either change the format ("is64kBitVector"?) or elide them for larger types.

Cheers,

James

I agree, it is not really needed I added it for consistency. I don't mind changing it to the format suggested. Which ones do you think should be changed?

LGTM

LGTM

In D53765#1367315, @craig.topper wrote:

In D53765#1367170, @majnemer wrote:

Do you have any tests which perform a callbr with a normal function target rather than inline asm?

No, and Verifier.cpp currently errors for it.

Do you have any tests which perform a callbr with a normal function target rather than inline asm?

LGTM

LGTM

FWIW, Microsoft's newest documentation does not say that /O2 and /O1 imply /Gs: https://docs.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=vs-2017

LGTM

LGTM

How does MSVC handle this case? What mangled name does it generate?

LGTM

LGTM

LGTM

In D49965#1179735, @zturner wrote:

I had thought of a tryDemangleNumber function but it didn’t really fit the
style of code . (Ie I don’t really do that anywhere else so it felt a
little out of place). I can still do that if you think it’s better, I don’t
have a strong preference

LGTM

I'm worried about some extreme template stuff (function templates are not considered for back-referencing but other templates and normal functions are OK) but you are gonna work thru the rest of mangle-ms-* so you'll get there ;)

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM with that final nit fixed.

In D45559#1093526, @aheejin wrote:

As I said above, the term 'funclet' seems to be used pretty everywhere including clang. To summarize its usage,

1. Small outlined functions themselves
2. Funcletpad instructions, such as catchpad or cleanuppad
3. The structure of BBs starting from catchpad/cleanuppad and ending with catchret/cleanupret, which can be nested
4. This Windows IR -based EH itself

Now I'm thinking that maybe we should use isFuncletEHPersonality for the use cases here I replaced with usesWindowsEHInstructions, and come up with a new name to give to the use cases that pertain to real outlined small functions.

LGTM