Hi,
Is anyone working on this? If not, I can have a look -- it would be nice to have a no_split_stacks attribute too.
Thanks,
Sanjoy
Hi,
Is anyone working on this? If not, I can have a look -- it would be nice to have a no_split_stacks attribute too.
Thanks,
Sanjoy
I’m pretty sure Kostya is working on it…
Just started, nothing to report yet.
But will continue today/tomorrow.
–kcc
The change is not just to replace “typedef unsigned Attributes” with “typedef uint64_t Attributes”.
The problem is that ‘unsigned’ is used instead of ‘Attributes’ all over the place.
How about implementing Attributes as a class with 64-bit integer under the hood?
This will protect us from erroneous casts to/from 32-bit unsigned.
I have a change half-done but I want to know llvmdev’s opinion before proceeding.
–kcc
Hi Kostya,
How about implementing Attributes as a class with 64-bit integer under the
hood?
This will protect us from erroneous casts to/from 32-bit unsigned.
I have a change half-done but I want to know llvmdev's opinion before
proceeding.
Yes, this sounds like a proper approach. Which will allow us to switch
over other implementation of attributes, if necessary.
+1
-Chris
Here is the preliminary patch.
It wraps the uint64_t bitmask into a class, but still provides “uint64_t Raw();”
(mostly for serialization/deserialization methods).
Before the full review, I’d like to get a general feedback: is this how we want this to be done?
The patch passes ‘make check’ on one platform, but needs more testing.
I also want to add at least one attribute after the 32-nd bit to verify that it works.
It may also make sense to move some functions (e.g. constructAlignmentFromInt) inside the class definition,
but I’d prefer to have it as a separate commit.
–kcc
attr_llvm.patch (23.3 KB)
attr_clang.patch (2.25 KB)