[PATCH] D25530: [MIRParser] Parse lane masks in block liveins

[Matthias Braun via llvm-commits]

> On Oct 12, 2016, at 2:01 PM, Krzysztof Parzyszek via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> On 10/12/2016 3:35 PM, Matthias Braun wrote:
>> 
>>> On Oct 12, 2016, at 12:47 PM, Krzysztof Parzyszek via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>> 
>>> May I suggest that floating-point hexadecimal values are required to have such a prefix?  Because that would be really nice. :)
>> I looked into that shortly and it seems we basically reuse the parsing infrastructure for .ll files for float literals. I am not sure we can/should change the .ll file syntax at this point.
> 
> Yes, but the MIR parser/printer could always require/emit a prefix. There is already a check for H, K, L or M, but those are never used in any .mir testcase. There is at least one for NVPTX that has floating point values given in hex, and it would need to have these prefixes added.
> MIR does not have implicit conversions from integer to floating-point, so there is no risk of having someone use a pure 0x... string with the intention of it being a bit-pattern for a floating point value, when it would be parsed as an integer, then implicitly converted to a float.
Sure we can (and in some ares should) change the syntax of .mir files. I assumed the printAsOperand() stuff used when printing MO_FPImmediate will use the same .ll printing code as well and therefore give you those prefixes when you hit exotic FP formats. At a first glance it looks like NVPTX has just IEEE754 32bit/64bit floats which would require no special prefix, while currently I cannot find any architecture using an exotic FP format having the concept of a floatingpoint immediate so I am not sure how to even test it. I'm not completely opposed to the idea of changing the .mir syntax however I think there is value in staying consistent with the odd .ll syntax as well and I'd lean toward staying with the .ll conventions.

> 
> I hope that the .ll parser understands the floating point prefixes. If not, we could still create a FloatingPointValue token, except it would have a string value with the prefix removed.
The .ll parser definitely does and needs them for an exact reproduction of floating point literals.

- Matthias