[llvm] r367711 - Add MCRegister and use it in MCRegisterClass::contains()

[Daniel Sanders via llvm-commits]

What kind of ambiguity errors do you mean? I've seen a couple different variants.

I definitely agree with making it explicit (and adding physreg/not-valid checks for the expensive checks bots) but it was necessary in the first instance to not have to bring a huge patch along with it. If you make it explicit, it causes 77 errors across 43 files before being unable to make further progress. Most of it is about using Register where only phys regs make sense (MCRegisterInfo::getDwarfRegNum(), traversing sub/super-reg relationships, MCRegUnitIterator, etc.)

By the way, last night I started looking into a clang-tidy check to make this mass-refactor to Register/MCRegister more practical. I was starting with `unsigned VarName = (implicit unsigned)(<Register-typed-expr>)` then `s/unsigned/Register/`. I expect we can add something like `(implicit MCRegister)(<Register-typed-expr>)` to `<Register-typed-expr>.getPhysReg()` to that.

> On Aug 7, 2019, at 08:19, Matt Arsenault <arsenm2 at gmail.com> wrote:
> 
> 
> 
>> On Aug 2, 2019, at 15:37, Daniel Sanders via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> 
>> +  operator MCRegister() const {
>> +    return MCRegister(Reg);
>> +  }
> 
> This is actually the opposite of what I intended. MCRegister->Register is OK, but implicit MCRegister->Register is not. I’m running into some ambiguity errors from this.
> 
> -Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190807/f59c3942/attachment.html>