[cfe-dev] Bitwidth attribute in clang
nadav256 at gmail.com
Fri Aug 8 06:03:37 PDT 2008
I enjoyed watching your presentation from the devmtg. It was very good.
I started with a different solution. I added a new 'unsigned bitwidth'
member to the BuiltinType. If it is set to zero then the default type
behaviour is used, otherwise the bitwidth field is used. With this
implementation I don't have to implement the signed/unsigned float/int
Would this also work ?
I have another question, For this code :
typedef int int4 __attribute__((bitwidth(4)));
I added a handle for the new attribute. From the handle I am given a
"TypedefDecl" object. From this I would like to get the definition of
the new type ("int4") and change it. However, the getUnderlyingType()
API returns the Type object for *int. I could not find the API to get
the Type object for "int4".
On Fri, Aug 8, 2008 at 2:35 PM, Steve Naroff <snaroff at apple.com> wrote:
> On Aug 8, 2008, at 2:49 AM, Nadav wrote:
>> I am working on adding attribute support for arbitrary integer bit
>> width for clang. This is useful for hardware synthesis where smaller
>> integers translate to smaller circuits.
>> There is a similar open bug against llvm-gcc which explains this.
>> typedef int int5 __attribute__((bitwidth(5)));
>> I followed efriedma's 51577 patch and added the new attribute syntax
>> without a problem.
>> I wanted to consult with the list on the best way to implement this.
>> It looks like the current type classes cannot support arbitrary
>> bitlength integers. The BuiltinType class supports only the standard
>> types (UChar, UInt, Int, etc). Would you suggest deriving another new
>> type from Type (similar to complex, pointer, etc). After I do this I
>> will have to change many other places in the code.
> To create the new type, you will have to modify Type, ASTContext, and Sema
> (ProcessDeclAttribute). See VectorType/ExtVectorType for a couple types
> created from attributes. Once the type is created, you will need to hack
> Sema for type checking/analysis.
>> Is there another better way to implement this ?
> Not really...you have the right idea.
>> Thank you,
>> Nadav Rotem
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
More information about the cfe-dev