[llvm-dev] TableGen processing of target-specific intrinsics
Paul C. Anagnostopoulos via llvm-dev
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...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Nicolai Hähnle via llvm-dev
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
--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
Paul C. Anagnostopoulos via llvm-dev
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
_______________________________________________
Reid Kleckner via llvm-dev
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.
Paul C. Anagnostopoulos via llvm-dev
Would it be possible to allow each target to generate its own intrinsic tables, and then write a program to merge them into one contiguous space?
At 9/30/2020 04:31 PM, Reid Kleckner wrote:
>On Wed, Sep 30, 2020 at 6:20 AM Nicolai Hähnle via llvm-dev <<mailto:llvm...@lists.llvm.org>llvm...@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>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.
_______________________________________________
Paul C. Anagnostopoulos via llvm-dev
At 9/30/2020 04:31 PM, Reid Kleckner wrote:
>On Wed, Sep 30, 2020 at 6:20 AM Nicolai Hähnle via llvm-dev <<mailto:llvm...@lists.llvm.org>llvm...@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>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.
_______________________________________________