ping

ping

I guess this is one way to do it

Also test pointers with different address spaces

In D147245#4236143, @foad wrote:

I had a quick look at some codegen differences this caused in Vulkan shaders compiled by LLPC. The biggest difference was that the DAG nodes for scalar loads now have a chain operand, which has a big effect on DAG scheduling.

In D147245#4234726, @mareko wrote:

Mesa sets "invariant.load" metadata on all "s.buffer.load" call sites. There are no pointers, only descriptors. Is that sufficient to get the readnone behavior?

In D146762#4236828, @krzysz00 wrote:

I wasn't sure if the general IR verifier is the absolute best place, but it already has calling-convention specific checks, which, at least in our case, are target specific.

In D145329#4236105, @nhaehnle wrote:

Yes, what I'm thinking of as a clean story would require changing the register allocator a little.

We don't have any real target specific verifier checks like this now. I do think we need some kind of target IR verifier, but just dropping this in like this is probably not the way to go about it

New version at D145329

Missing tests

LGTM. I"m assuming the other diffs somehow make this worthwhile since currently there's only 5 values

LGTM. I would assume this is the ordering anonymous records would get and it shouldn't really matter

Obsoleted by D147245

LGTM. Seems like an error in the kill flag insertion

I think we need to have LiveRangeEdit start doing the same thing. I guess we can start with this in a separate pass for now, and then I can look into merge it into LiveRangeEdit. One of the problems I'm trying to solve is tuple spills increasing liveness for dead lanes

In D147096#4229413, @cfang wrote:

In D147096#4229261, @cdevadas wrote:

What will happen to getMinimalPhysRegClass query for SGPR_64 registers?
If this returns the new register class, ccr_sgpr_64, that's not the desired behavior.

getMinimalPhysRegClass should always return the minimal physical register class. I think CCR_SGPR_64
has all the properties of SGPR_64, so we won't have any issue for the (srcReg, RC) pair.

In D146940#4233004, @Pierre-vh wrote:

I'd also rather just delete it now - especially because there's no reason not to use UA, but I thought deprecation was a mandatory step.

Description is imprecise. It's a subclass, not a subregister class.

I thought calls to aliases were generally folded to direct calls at some point, so is there just an ordering issue?

ping

ping

3b44109b71a17abb087cfb0ee1a4fd0b7d5096a5

In D144590#4220648, @ZwFink wrote:

I wanted to follow up on this. Is anything additional needed from me?

LGTM with test nit

LGTM, thanks I noticed this when I was fixing printf recently but forgot to fix this part

In D145290#4210633, @JonChesterfield wrote:

LGTM but Matt's the expert here

It's a sketchy function to begin with, making a lot of assumptions about what a call looks like.

ping

Should ByteProvider really be BitProvider?

Unrelated but PromoteAllocaToVectorLimit should really move to a new PM pass parameter

ec2234a21a5dbffcc7b8eb0996e3aba288a4009a

In D146142#4202327, @arsenm wrote:

b5ff7640cd1391ebe67e47a043fed6faf8bdcbb7