[cfe-dev] Target-specific AST rewriting (clang)

[Krzysztof Parzyszek via cfe-dev]

Assume for brevity that
vector_int = __attribute__((__vector_size__(32 * sizeof(int)))) int
vector_bool = __attribute__((__vector_size__(128 * sizeof(_Bool)))) _Bool

Consider this AST.  It contains bitcasts from vector_bool to vector_int and the other way around.

|     `-ImplicitCastExpr 0x807c212b0 <col:10, col:51> 'HVX_Vector':'vector_int' <BitCast>
|       `-CallExpr 0x807c21220 <col:10, col:51> 'vector_bool'
|         |-ImplicitCastExpr 0x807c21208 <col:10> 'vector_bool (*)(vector_bool, vector_bool)' <BuiltinFnToFnPtr>
|         | `-DeclRefExpr 0x807c21180 <col:10> '<builtin fn type>' Function 0x807c21000 '__builtin_HEXAGON_V6_pred_and_128B' 'vector_bool (vector_bool, vector_bool)'
|         |-ImplicitCastExpr 0x807c21268 <col:45> 'vector_bool' <BitCast>
|         | `-ImplicitCastExpr 0x807c21250 <col:45> 'HVX_Vector':'vector_int' <LValueToRValue>
|         |   `-DeclRefExpr 0x807c211a0 <col:45> 'HVX_Vector':'vector_int' lvalue ParmVar 0x807a43d10 'a0' 'HVX_Vector':'vector_int'
|         `-ImplicitCastExpr 0x807c21298 <col:49> 'vector_bool' <BitCast>
|           `-ImplicitCastExpr 0x807c21280 <col:49> 'HVX_Vector':'vector_int' <LValueToRValue>
|             `-DeclRefExpr 0x807c211c0 <col:49> 'HVX_Vector':'vector_int' lvalue ParmVar 0x807a43d88 'a1' 'HVX_Vector':'vector_int'


  1.  These casts are not no-ops, there are instructions that do it (with corresponding builtins/intrinsics). In the actual hardware, the registers holding vector_int are 1024 bits long, the registers holding vector_bool are 128 bits long.
  2.  The "bool" vectors are not storable directly (i.e. no way to store the 128 bits to memory).  Instead, they have to be "expanded" into vector_int (or contracted from vector_int).  In other words, vector_int is the universal storage format for both types.

Long story short, in C code we want to make these two types look (more or less) the same (i.e. both are 128 bytes), but in LLVM IR they are different (since 32*i32 is not bitcastable to 128*i1).  Now, I want to replace these bitcasts with calls to proper builtins, i.e. transform clang's Expr to another Expr.  Right now we deal with it in CGBuiltin as a part of codegen, but it's not elegant (not composable with other per-builtin handling that may need to happen in CGBuiltin).

-Krzysztof

________________________________
From: Eli Friedman <efriedma at quicinc.com>
Sent: Monday, March 9, 2020 4:42 PM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>
Cc: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: RE: [EXT] [cfe-dev] Target-specific AST rewriting (clang)

I'm not sure I follow what you mean.  Do you mean that given, for example "float x; __builtin_foo(-x);", you call "llvm.foo(-x)", and given "double x; __builtin_foo((float)-x)", you call "llvm.bar(-x)"?  I don't think there's any precedent for that, no; normally that's the sort of optimization you'd handle in instcombine.

-Eli

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Krzysztof
> Parzyszek via cfe-dev
> Sent: Monday, March 9, 2020 12:57 PM
> To: cfe-dev at lists.llvm.org
> Subject: [EXT] [cfe-dev] Target-specific AST rewriting (clang)
>
> Hi,
>
> There are some type casts that should be replaced with intrinsics (this is
> Hexagon-specific). Those only occur in calls to Hexagon builtins, and right now
> this replacement happens as a part of clang's codegen.
> However, this replacement is only triggered by types in the AST and the
> corresponding types in the LLVM IR, and is not dependent on the details
> (semantics) of any particular builtin, so I'd like to make it orthogonal to the
> cgbuiltin code that deals with specific intrinsics. I'd like the replacement to
> transform AST->AST, so the result can be easily composed with any code that
> does AST->LLVM IR.
>
> Is there a precedent for something like this?  I could do this right at the
> beginning of EmitHexagonBuiltinExpr, but I was wondering if there was a better
> way.
>
> --
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200309/f4cc8008/attachment-0001.html>