8000
We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
c2e3b8b
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Why are you changing the function signature? Why wasn't it getAddrOfBitFieldStorage in the first place?
getAddrOfBitFieldStorage
Sorry, something went wrong.
The function was introduced by me and in previous version it was not intended to work with bitfields only. After the last changes it will serve only them though. That's why I renamed it and added one more argument
Sounds good.
Please explain why it shouldn't use convertType here.
convertType
convertType for the integer field is always 32, type mismatch guaranteed, see a longer comment below
So please add assert(convertType(field->getType()) == ...)
assert(convertType(field->getType()) == ...)
What's LLVM codegen doing here? Does it call getAddrOfBitFieldStorage or getAddrOfField?
getAddrOfField
there is no LLVM codegen here.
I mean, we follow the principle of using the same skeleton as clang/lib/CodeGen, at least to the extend of what's possible.
clang/lib/CodeGen
I don't see anything similar to getAddrOfBitFieldStorage or getAddrOfField in clang/lib/CodeGen/*, and I want to understand what's the rationale there. Are those names introduced for specific functionality you refactor into helpers or are they complete new names for something that already existed in clang/lib/CodeGen? If so, I'm trying to understand why can't you just s/Emit/build and call it a day?
clang/lib/CodeGen/*
s/Emit/build