https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/102462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,12 +1,14 @@
; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
; in the special case when those intrinsics are being generated by the
CodeGenPrepare;
-; pass during translations with optimization (note -O3 in llc arguments).
+; pass during
arsenm wrote:
> WRT eliminating the constrained intrinsics completely, I thought that operand
> bundles could only be attached to function calls and not regular
> instructions? If I'm wrong, we _still_ have a problem because there are so
> many uses of the regular FP instructions that we can't
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -784,6 +791,20 @@ bool SystemZTargetLowering::useSoftFloat() const {
return Subtarget.hasSoftFloat();
}
+MVT SystemZTargetLowering::getRegisterTypeForCallingConv(
+ LLVMContext &Context, CallingConv::ID CC,
+ EVT VT) const {
+ // 128-bit single-element vector t
@@ -1597,6 +1618,15 @@ bool SystemZTargetLowering::splitValueIntoRegisterParts(
return true;
}
+ // Convert f16 to f32 (Out-arg).
+ if (PartVT == MVT::f16) {
+assert(NumParts == 1 && "");
arsenm wrote:
Remove && "" or make it a meaningful message
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -0,0 +1,201 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z16 | FileCheck %s
+;
+; Tests for 16-bit floating point (half).
+
+; Incoming half arguments added together and
@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu \
+// RUN: -ffloat16-excess-precision=standard -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=STANDARD
+
+// RUN: %clang_cc1 -triple s390x-linux-gnu \
+// RUN: -ffloat16-excess-precision=none -emit-llvm -o -
@@ -784,6 +791,20 @@ bool SystemZTargetLowering::useSoftFloat() const {
return Subtarget.hasSoftFloat();
}
+MVT SystemZTargetLowering::getRegisterTypeForCallingConv(
+ LLVMContext &Context, CallingConv::ID CC,
+ EVT VT) const {
+ // 128-bit single-element vector t
arsenm wrote:
> Think it would be useful to put that on functions in the wrapper headers that
> definitely aren't convergent? E.g. getting a thread id.
You could, but it's trivially inferable in those cases anyway
https://github.com/llvm/llvm-project/pull/111076
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/111076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4106,9 +4106,10 @@ bool CompilerInvocation::ParseLangArgs(LangOptions
&Opts, ArgList &Args,
Opts.Blocks = Args.hasArg(OPT_fblocks) || (Opts.OpenCL
&& Opts.OpenCLVersion == 200);
- Opts.ConvergentFunctions = Args.hasArg(OPT_fconvergent_functions) ||
-
arsenm wrote:
> -fno-convergent-functions to opt-out if you want to test broken behavior.
You may legitimately know there are no convergent functions in the TU. We also
have the noconvergent source attribute now for this
https://github.com/llvm/llvm-project/pull/111076
__
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
@@ -178,6 +266,9 @@ void SPIRVPassConfig::addIRPasses() {
addPass(createSPIRVStructurizerPass());
}
+ if (TM.getOptLevel() > CodeGenOptLevel::None)
+addPass(createInferAddressSpacesPass(AddressSpace::Generic));
arsenm wrote:
Not sure why this is a
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T,
const Triple &TT,
setRequiresStructuredCFG(false);
}
+enum AddressSpace {
+ Function = storageClassToAddressSpace(SPIRV::StorageClass::Function),
+ CrossWorkgroup =
+ storageClassToAddressSpac
@@ -0,0 +1,29 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
arsenm wrote:
You don't need to duplicate all of these tests. You just need some basic
samples that the target is implemented, the full set is testing pass mechanics
whi
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1660,7 +1660,7 @@ class Record {
// this record.
SmallVector Locs;
SmallVector ForwardDeclarationLocs;
- SmallVector ReferenceLocs;
+ mutable SmallVector ReferenceLocs;
arsenm wrote:
You have the const_cast on the addition, so this is unnecessary?
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
The codegen prepare behavior is still backend code to be tested. You can just
run codegenprepare as a standalone pass too (usually would have sepa
@@ -0,0 +1,102 @@
+//===-- LLVMTargetMachineC.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
arsenm wrote:
> with the PR pulled in (on top of LLVM's HEAD
> [aadfba9](https://github.com/llvm/llvm-project/commit/aadfba9b2aa107f9cada2fd9bcbe612cbf560650)),
> the compilation command is: `clang++ -cl-std=CL2.0 -emit-llvm -c -x cl -g0
> --target=spir -Xclang -finclude-default-header -O2 tes
arsenm wrote:
> 1. Usually (or at least AFAIK) optimization passes won't consider datalayout
> automatically,
The datalayout is a widely used global constant. There's no option of "not
considering it"
> Do you plan to go over LLVM passes adding this check?
There's nothing new to do here. T
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/110695
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
> Right but it's relying on a non-guaranteed maybe-optimisation firing, as far
> as I can tell.
The point is to test the optimization does work.
arsenm wrote:
> > I would like to avoid adding additional special properties to AS0, or
> > defining the flat concept.
>
> How can we add a new specification w/o defining it?
By not defining it in terms of flat addressing. Just make it the undesirable
address space
https://github.com/llvm/ll
@@ -54,14 +54,14 @@ static std::string computeDataLayout(const Triple &TT) {
// memory model used for graphics: PhysicalStorageBuffer64. But it shouldn't
// mean anything.
if (Arch == Triple::spirv32)
-return "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-"
-
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
That is not the nature of this kind of test
https://github.com/llvm/llvm-project/pull/110695
___
cfe-c
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
This one is testing codegenprepare as part of the normal codegen pipeline, so
this one is fine. The other case was a full optimization pipeline +
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
Not sure what the problem is with this test, but it's already covered by
another?
https://github.com/llvm/llvm-project/pull/110695
_
@@ -54,14 +54,14 @@ static std::string computeDataLayout(const Triple &TT) {
// memory model used for graphics: PhysicalStorageBuffer64. But it shouldn't
// mean anything.
if (Arch == Triple::spirv32)
-return "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-"
-
@@ -1122,6 +1122,26 @@ define void @fastMathFlagsForArrayCalls([2 x float] %f,
[2 x double] %d1, [2 x <
ret void
}
+declare { float, float } @fmf_struct_f32()
+declare { double, double } @fmf_struct_f64()
+declare { <4 x double>, <4 x double> } @fmf_struct_v4f64()
+
+; CHEC
arsenm wrote:
> * Move the MC emission functions in `TargetMachine` to `LLVMTargetMachine`.
> With the changes in this PR, we explicitly assume in both
> `addPassesToEmitFile` and `addPassesToEmitMC` that the `TargetMachine` is an
> `LLVMTargetMachine`; Hence it does not make sense for these f
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110032
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
> With the constrained intrinsics the default is safe because optimizations
> don't recognize the constrained intrinsic and thus don't know how to optimize
> it. If we instead rely on the strictfp attribute then we'll need possibly
> thousands of checks for this attribute, we'll
@@ -1556,7 +1557,7 @@ class RecordVal {
bool IsUsed = false;
/// Reference locations to this record value.
- SmallVector ReferenceLocs;
+ mutable SmallVector ReferenceLocs;
arsenm wrote:
Is this removed in later patches?
https://github.com/llvm/llvm-p
@@ -273,6 +273,74 @@ void test_builtin_elementwise_min(int i, short s, double
d, float4 v, int3 iv, u
// expected-error@-1 {{1st argument must be a vector, integer or floating
point type (was '_Complex float')}}
}
+void test_builtin_elementwise_maximum(int i, short s, floa
@@ -706,6 +706,12 @@ Unless specified otherwise operation(±0) = ±0 and
operation(±infinity) = ±in
representable values for the
signed/unsigned integer type.
T __builtin_elementwise_sub_sat(T x, T y) return the difference of x and
arsenm wrote:
If it's not legal for it to be marked as constant, it's also not legal to use
constant address space
https://github.com/llvm/llvm-project/pull/110182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
arsenm wrote:
> Both in InferAddressSpaces, and in Attributor, you don't really care about
> whether a flat address-space exists.
Right, this is more of an undesirable address space. Optimizations don't need
to know anything about its behavior beyond that.
> In reply to your question above
@@ -579,7 +579,7 @@ static StringRef computeDataLayout(const Triple &TT) {
"-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-"
"v32:32-v48:64-v96:"
"128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-"
- "G
arsenm wrote:
> Just to clarify, does this mean any two non-flat address space pointers
> _cannot_ alias?
This should change nothing about aliasing. The IR assumption is any address
space may alias any other
https://github.com/llvm/llvm-project/pull/108786
___
arsenm wrote:
> There are targets that use a different integer to denote flat (e.g. see SPIR
> & SPIR-V). Whilst I know that there are objections to that, the fact remains
> that they had historical reason (wanted to make legacy OCL convention that
> the default is private work, and given that
@@ -66,12 +66,12 @@ NVPTXTargetInfo::NVPTXTargetInfo(const llvm::Triple &Triple,
HasFloat16 = true;
if (TargetPointerWidth == 32)
-resetDataLayout("e-p:32:32-i64:64-i128:128-v16:16-v32:32-n16:32:64");
+resetDataLayout("e-p:32:32-i64:64-i128:128-v16:16-v32:32-n16:32
https://github.com/arsenm approved this pull request.
I think we need more thought about how the ABI for this will work, but we need
to start somewhere
https://github.com/llvm/llvm-project/pull/102913
___
cfe-commits mailing list
cfe-commits@lists.ll
arsenm wrote:
> If we can't keep the constrained semantics and near-100% guarantee that no
> new exceptions will be introduced then operand bundles are not a replacement
> for the constrained intrinsics.
We would still need a call / function attribute to indicate strictfp calls, and
such call
https://github.com/arsenm edited https://github.com/llvm/llvm-project/pull/94647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -434,6 +434,15 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
indicatePessimisticFixpoint();
return;
}
+
+for (Instruction &I : instructions(F)) {
+ if (isa(I) &&
arsenm wrote:
Simple example, where the cast is still d
@@ -434,6 +434,15 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
indicatePessimisticFixpoint();
return;
}
+
+for (Instruction &I : instructions(F)) {
+ if (isa(I) &&
arsenm wrote:
5->3 is an illegal address space cast, bu
arsenm wrote:
Also it's silly that we need to do bitcode autoupgrade of "experimental"
intrinsics, but x86 started shipping with strictfp enabled in production before
they graduated. We might as well drop the experimental bit then
https://github.com/llvm/llvm-project/pull/109798
_
@@ -357,6 +357,9 @@ class IRBuilderBase {
void setConstrainedFPCallAttr(CallBase *I) {
I->addFnAttr(Attribute::StrictFP);
+MemoryEffects ME = MemoryEffects::inaccessibleMemOnly();
arsenm wrote:
It shouldn't be necessary to touch the attributes. The
@@ -78,15 +78,15 @@ void MCResourceInfo::finalize(MCContext &OutContext) {
}
MCSymbol *MCResourceInfo::getMaxVGPRSymbol(MCContext &OutContext) {
- return OutContext.getOrCreateSymbol("max_num_vgpr");
+ return OutContext.getOrCreateSymbol("amdgcn.max_num_vgpr");
-
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/109894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
Superseded by #108853
https://github.com/llvm/llvm-project/pull/107598
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm closed
https://github.com/llvm/llvm-project/pull/107598
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/108853
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
> If we already have per-function metadata, I'm wondering how difficult it
> would be to put this handling in the linker. AFAIK there's already handling
> for `call-graph-profile` which can inform the linker of the call-graph, so we
> could potentially just walk that graph, find
https://github.com/arsenm approved this pull request.
LGTM, but like I mentioned on #107598, it would be good if there was a test
that requires the argument check, and the return check isn't sufficient
https://github.com/llvm/llvm-project/pull/108853
___
arsenm wrote:
> So it should be built along with the core of LLVM? Also, we package LLVM per
> version per subproject.
Yes, it should be built along with the core (but doesn't need to ship in the
same package as the core).
https://github.com/llvm/llvm-project/pull/105969
__
arsenm wrote:
> Nixpkgs has no intention of moving away from standalone builds.
I encourage you to acquire that intention. IMO libclc should not support the
standalone build, and this should be version locked to the exact compiler
commit. It's compiler data, not a real library
https://github
https://github.com/arsenm commented:
The nix build should probably migrate to using the non-standalone build
https://github.com/llvm/llvm-project/pull/105969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -55,7 +55,7 @@ if( LIBCLC_STANDALONE_BUILD OR CMAKE_SOURCE_DIR STREQUAL
CMAKE_CURRENT_SOURCE_DI
# Import required tools
if( NOT EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
foreach( tool IN ITEMS clang llvm-as llvm-link opt )
- find_program( LLVM_TOOL_${tool
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/105969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
> @aeubanks @arsenm after looking into this in more detail, I realized that the
> `getContext` method of `MMI` is heavily used in the `AsmPrinter` to create
> symbols. Also not having it makes it harder for the `MMI` to create machine
> functions using `getOrCreateMachineFunction
@@ -774,18 +774,27 @@ class buffer_unique_ostream : public raw_svector_ostream {
// you can use
// OS << indent(6) << "more stuff";
// which has better ergonomics (and clang-formats better as well).
+//
+// If indentation is always in increments of a fixed value, you can use Sc
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/109478
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
> @aeubanks It's not impossible to separate them completely. `MCContext` is
> needed during initialization and finalization of the
> `MachineModuleInfoWrapperPass` (and its new pass manager variant) to set the
> diagnostics handler.
>
> In theory, you can just pass the context t
@@ -1806,7 +1806,7 @@ bool AMDGPUDAGToDAGISel::SelectGlobalSAddr(SDNode *N,
// instructions to perform VALU adds with immediates or inline literals.
unsigned NumLiterals =
!TII->isInlineConstant(APInt(32, COffsetVal & 0x)) +
- !TII->isInli
@@ -4377,7 +4377,7 @@
AMDGPUInstructionSelector::selectGlobalSAddr(MachineOperand &Root) const {
// instructions to perform VALU adds with immediates or inline
literals.
unsigned NumLiterals =
!TII.isInlineConstant(APInt(32, ConstOffset & 0xfff
@@ -690,23 +690,46 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(call
@@ -678,6 +690,37 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
return !A.checkForAllCallLikeInstructions(DoesNotRetrieve, *this,
UsedAssumedInformation);
}
+
+ // Returns true if FlatScratchInit is needed, i.e
@@ -678,6 +690,37 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
return !A.checkForAllCallLikeInstructions(DoesNotRetrieve, *this,
UsedAssumedInformation);
}
+
+ // Returns true if FlatScratchInit is needed, i.e
@@ -434,6 +434,15 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
indicatePessimisticFixpoint();
return;
}
+
+for (Instruction &I : instructions(F)) {
+ if (isa(I) &&
arsenm wrote:
For a nightmare of an edge case, addrspac
arsenm wrote:
Replaced by #108596
https://github.com/llvm/llvm-project/pull/92809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm closed https://github.com/llvm/llvm-project/pull/92809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -40,12 +42,19 @@ class AMDGPUAsmPrinter final : public AsmPrinter {
AMDGPUResourceUsageAnalysis *ResourceUsage;
+ MCResourceInfo RI;
+
SIProgramInfo CurrentProgramInfo;
std::unique_ptr HSAMetadataStream;
MCCodeEmitter *DumpCodeInstEmitter = nullptr;
+ //
@@ -0,0 +1,225 @@
+//===- AMDGPUMCResourceInfo.cpp --- MC Resource Info
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,225 @@
+//===- AMDGPUMCResourceInfo.cpp --- MC Resource Info
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 %s -O3 -fmath-errno -emit-llvm -triple
x86_64-unknown-unknown -o - %s | FileCheck %s -check-prefixes=CHECK
+// RUN: %clang_cc1 %s -O3 -fmath-errno -emit-llvm -triple x86_64-pc-win64 -o -
%s | FileCheck %s -check-prefixes=CHECK
+// RUN: %clan
@@ -686,6 +686,20 @@ static Value *EmitSignBit(CodeGenFunction &CGF, Value *V) {
return CGF.Builder.CreateICmpSLT(V, Zero);
}
+static bool hasPointerArgsOrPointerReturnType(const Value *V) {
+ if (const CallBase *CB = dyn_cast(V)) {
+for (const Value *A : CB->args()) {
@@ -699,9 +713,12 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
bool ConstWithoutErrnoAndExceptions =
Context.BuiltinInfo.isConstWithoutErrnoAndExceptions(BuiltinID);
// Restrict to target with errno, for example, MacOS doesn't
@@ -686,6 +686,20 @@ static Value *EmitSignBit(CodeGenFunction &CGF, Value *V) {
return CGF.Builder.CreateICmpSLT(V, Zero);
}
+static bool hasPointerArgsOrPointerReturnType(const Value *V) {
+ if (const CallBase *CB = dyn_cast(V)) {
+for (const Value *A : CB->args()) {
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
+ SmallVector SSNs;
+ Ctx.getSyncScopeNames(SSNs);
+
+ StringRef M
@@ -699,9 +699,20 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
bool ConstWithoutErrnoAndExceptions =
Context.BuiltinInfo.isConstWithoutErrnoAndExceptions(BuiltinID);
// Restrict to target with errno, for example, MacOS doesn't
@@ -699,9 +699,20 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
bool ConstWithoutErrnoAndExceptions =
Context.BuiltinInfo.isConstWithoutErrnoAndExceptions(BuiltinID);
// Restrict to target with errno, for example, MacOS doesn't
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
+ SmallVector SSNs;
+ Ctx.getSyncScopeNames(SSNs);
+
+ StringRef M
@@ -58,7 +58,35 @@ class SPIRVTargetCodeGenInfo : public
CommonSPIRTargetCodeGenInfo {
SPIRVTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: CommonSPIRTargetCodeGenInfo(std::make_unique(CGT)) {}
void setCUDAKernelCallingConvention(const FunctionType *&FT) const overri
@@ -766,8 +766,19 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr
*Expr, Address Dest,
// LLVM atomic instructions always have synch scope. If clang atomic
// expression has no scope operand, use default LLVM synch scope.
if (!ScopeModel) {
+llvm::SyncSc
arsenm wrote:
> Hi, @paulwalker-arm, ACLE allows users to do instruction-level development,
> but mixing intrinsic and regular C code may break some of the rules set by
> the compiler.
The rules are still there. You can always use a union or copy to avoid
violating the rules. I don't think i
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/89051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
lgtm assuming the const_cast goes away in a subsequent change
https://github.com/llvm/llvm-project/pull/107692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
arsenm wrote:
I don't understand this. The code is a strict aliasing violation, so why should
clang work around it?
https://github.com/llvm/llvm-project/pull/107793
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
201 - 300 of 1584 matches
Mail list logo
