[PATCH] D102220: [NFC, CFI] Use unsigned type for CFI register values in parser/streamer code
Venkata Ramanaiah Nalamothu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed May 12 21:06:03 PDT 2021
RamNalamothu added a comment.
In D102220#2755984 <https://reviews.llvm.org/D102220#2755984>, @MaskRay wrote:
> In D102220#2755883 <https://reviews.llvm.org/D102220#2755883>, @RamNalamothu wrote:
>
>> In D102220#2755545 <https://reviews.llvm.org/D102220#2755545>, @MaskRay wrote:
>>
>>>> the interfacing code in parsers and streamers are using both signed and unsigned type in different parts.
>>>
>>> Where is uint64_t used? Most places use int64_t.
>>
>> For instance in `AsmParser::parseRegisterOrRegisterNumber()` and type cast in `MCStreamer::emitCFIDefCfaRegister()`.
bool AsmParser::parseRegisterOrRegisterNumber(int64_t &Register, ---> signed for register
SMLoc DirectiveLoc) {
unsigned RegNo; ---> unsigned for register
if (getLexer().isNot(AsmToken::Integer)) {
if (getTargetParser().ParseRegister(RegNo, DirectiveLoc, DirectiveLoc))
return true;
Register = getContext().getRegisterInfo()->getDwarfRegNum(RegNo, true);
} else
return parseAbsoluteExpression(Register);
return false;
}
>> Anyway, I have changed the summary as the above scenarios are minor in the entire changes.
>
> Both `AsmParser::parseRegisterOrRegisterNumber()` and `MCStreamer::emitCFIDefCfaRegister()` uses int64_t.
>
> OK, I am now convinced that most places use int64_t.
> Using unsigned type to represent "negative values aren't allowed" is not a good idea.
Looks like I couldn't get the intent of this patch expressed better earlier.
This patch is based on the fact that we don't use negative numbers to represent registers in CFI, meaning DWARF register mappings always use positive numbers or at least that is what I understood. Based on that, if not using register names in CFI directives, we never emit
`.cfi_register -2020, 2050` ---> value of register `-2020` is saved in register `2050`.
So, does it make sense to use an unsigned type for a variable which is not expected to have negative numbers?
And that is what this patch is trying to achieve.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D102220/new/
https://reviews.llvm.org/D102220
More information about the llvm-commits
mailing list