llvm dev - Sep 2020 - TableGen processing of target-specific intrinsics

Each of the main TableGen files for the supported targets includes

include "llvm/Target/Target.td"

In turn, Target.td includes

include "llvm/IR/Intrinsics.td"

The final lines of Instrinsics.td are

include "llvm/IR/IntrinsicsPowerPC.td"
include "llvm/IR/IntrinsicsX86.td"
include "llvm/IR/IntrinsicsARM.td"
include "llvm/IR/IntrinsicsAArch64.td"
include "llvm/IR/IntrinsicsXCore.td"
include "llvm/IR/IntrinsicsHexagon.td"
include "llvm/IR/IntrinsicsNVVM.td"
include "llvm/IR/IntrinsicsMips.td"
include "llvm/IR/IntrinsicsAMDGPU.td"
include "llvm/IR/IntrinsicsBPF.td"
include "llvm/IR/IntrinsicsSystemZ.td"
include "llvm/IR/IntrinsicsWebAssembly.td"
include "llvm/IR/IntrinsicsRISCV.td"

Why does every target include the all the instrinsics for all the targets?

For example, when I process the ARC TableGen file, the records include 1,187
intrinsics for the X86.

Hi Paul,

the intrinsics of all backends together with the target-agnostic
intrinsics are all part of a single large enum, and there are some
subtle assumptions made e.g. about how the values in this enum are
sorted (in order to emit tables that are suitable for binary search).
So this is an area in which to tread carefully.

That said, I don't think there's any inherent reason why we
_shouldn't_ try to entangle this a bit.

I've been thinking for a while now that in a sense, the
target-specific intrinsics are like a dialect of LLVM IR. It would
make sense to treat them as such more explicitly.

Cheers,
Nicolai

On Tue, Sep 29, 2020 at 9:23 PM Paul C. Anagnostopoulos via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Each of the main TableGen files for the supported targets includes
>
> include "llvm/Target/Target.td"
>
> In turn, Target.td includes
>
> include "llvm/IR/Intrinsics.td"
>
> The final lines of Instrinsics.td are
>
> include "llvm/IR/IntrinsicsPowerPC.td"
> include "llvm/IR/IntrinsicsX86.td"
> include "llvm/IR/IntrinsicsARM.td"
> include "llvm/IR/IntrinsicsAArch64.td"
> include "llvm/IR/IntrinsicsXCore.td"
> include "llvm/IR/IntrinsicsHexagon.td"
> include "llvm/IR/IntrinsicsNVVM.td"
> include "llvm/IR/IntrinsicsMips.td"
> include "llvm/IR/IntrinsicsAMDGPU.td"
> include "llvm/IR/IntrinsicsBPF.td"
> include "llvm/IR/IntrinsicsSystemZ.td"
> include "llvm/IR/IntrinsicsWebAssembly.td"
> include "llvm/IR/IntrinsicsRISCV.td"
>
> Why does every target include the all the instrinsics for all the targets?
>
> For example, when I process the ARC TableGen file, the records include
1,187 intrinsics for the X86.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

If I decide to tackle this issue, I will certainly post a proposal first. I
think it will be down the road a bit, as I learn more about how the system
works.

Is there a place online where the results of a full build are posted?


At 9/30/2020 09:20 AM, Nicolai Hähnle wrote:
>Hi Paul,
>
>the intrinsics of all backends together with the target-agnostic
>intrinsics are all part of a single large enum, and there are some
>subtle assumptions made e.g. about how the values in this enum are
>sorted (in order to emit tables that are suitable for binary search).
>So this is an area in which to tread carefully.
>
>That said, I don't think there's any inherent reason why we
>_shouldn't_ try to entangle this a bit.
>
>I've been thinking for a while now that in a sense, the
>target-specific intrinsics are like a dialect of LLVM IR. It would
>make sense to treat them as such more explicitly.
>
>Cheers,
>Nicolai

On Wed, Sep 30, 2020 at 6:20 AM Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Paul,
>
> the intrinsics of all backends together with the target-agnostic
> intrinsics are all part of a single large enum, and there are some
> subtle assumptions made e.g. about how the values in this enum are
> sorted (in order to emit tables that are suitable for binary search).
> So this is an area in which to tread carefully.
>
Strictly speaking, they are no longer part of the same enum:
http://github.com/llvm/llvm-project/commit/5d986953c8b917bacfaa1f800fc1e242559f76be
But yes, they use the same enumerator space, and tablgen processes them all
at once.

Processing intrinsics separately by target requires dividing the 32-bit
intrinsic opcode space up front. For example, we could use 8 bits for
target, 24 for intrinsics. This would make intrinsic ids no longer dense,
and no longer suitable as array indices, but perhaps having distinct arrays
per target is better anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200930/fb85d322/attachment.html>