tarunprabhu wrote:
@nikic
Could you take a look again and see if your concerns have been addressed.
https://github.com/llvm/llvm-project/pull/142686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
https://github.com/tarunprabhu approved this pull request.
Thanks for seeing this through
https://github.com/llvm/llvm-project/pull/142686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/142686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -52,6 +52,15 @@
// CHECK-INTERCHANGE-LOOPS: "-floop-interchange"
// CHECK-NO-INTERCHANGE-LOOPS: "-fno-loop-interchange"
+// RUN: %clang -### -S -fexperimental-loop-fusion %s 2>&1 | FileCheck
-check-prefix=CHECK-FUSE-LOOPS %s
tarunprabhu wrote:
I was partl
@@ -6870,6 +6870,8 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
options::OPT_fno_unroll_loops);
Args.AddLastArg(CmdArgs, options::OPT_floop_interchange,
options::OPT_fno_loop_interchange);
+ Args.addOptInFlag(CmdArgs,
@@ -43,6 +43,7 @@ CODEGENOPT(StackArrays, 1, 0) ///< -fstack-arrays (enable the
stack-arrays pass)
CODEGENOPT(VectorizeLoop, 1, 0) ///< Enable loop vectorization.
CODEGENOPT(VectorizeSLP, 1, 0) ///< Enable SLP vectorization.
CODEGENOPT(InterchangeLoops, 1, 0) ///< Enable loop
@@ -52,6 +52,15 @@
// CHECK-INTERCHANGE-LOOPS: "-floop-interchange"
// CHECK-NO-INTERCHANGE-LOOPS: "-fno-loop-interchange"
+// RUN: %clang -### -S -fexperimental-loop-fusion %s 2>&1 | FileCheck
-check-prefix=CHECK-FUSE-LOOPS %s
tarunprabhu wrote:
This should
https://github.com/tarunprabhu approved this pull request.
LGTM. Thanks
https://github.com/llvm/llvm-project/pull/154638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
Does this affect clang as well? If we do decide to disable it, will it only be
in flang, or in both clang and flang? If the latter, we should check with the
clang developers as well.
https://github.com/llvm/llvm-project/pull/140182
___
tarunprabhu wrote:
> > > What do you think is the right place in pass pipeline?
> > I don't know, but just a gut feeling, somewhere in
> > `buildModuleOptimizationPipeline` looks reasonable to me rather than
> > `buildFunctionSimplificationPipeline`.
> Yeah, I don't have enough data to support
@@ -855,17 +855,26 @@ void ToolChain::addFortranRuntimeLibs(const ArgList &Args,
void ToolChain::addFortranRuntimeLibraryPath(const llvm::opt::ArgList &Args,
ArgStringList &CmdArgs) const {
- // Default to the /../lib directory. Th
@@ -322,6 +322,7 @@ CODEGENOPT(TimeTrace , 1, 0, Benign) ///< Set when
-ftime-trace is enabl
VALUE_CODEGENOPT(TimeTraceGranularity, 32, 500, Benign) ///< Minimum time
granularity (in microseconds),
///< traced by
@@ -32,6 +32,9 @@ page](https://llvm.org/releases/).
## New Compiler Flags
+* -floop-interchange is now recognized by flang.
+* -fexperimental-loop-fuse is now recognized by flang.
tarunprabhu wrote:
```suggestion
* -fexperimental-loop-fusion is now recogniz
@@ -43,6 +43,7 @@ CODEGENOPT(StackArrays, 1, 0) ///< -fstack-arrays (enable the
stack-arrays pass)
CODEGENOPT(VectorizeLoop, 1, 0) ///< Enable loop vectorization.
CODEGENOPT(VectorizeSLP, 1, 0) ///< Enable SLP vectorization.
CODEGENOPT(InterchangeLoops, 1, 0) ///< Enable loop
@@ -1671,6 +1671,11 @@ void CompilerInvocationBase::GenerateCodeGenArgs(const
CodeGenOptions &Opts,
else
GenerateArg(Consumer, OPT_fno_loop_interchange);
+ if (Opts.FuseLoops)
+GenerateArg(Consumer, OPT_fexperimental_loop_fuse);
+ else
+GenerateArg(Consumer, O
@@ -151,6 +151,8 @@ void Flang::addCodegenOptions(const ArgList &Args,
!stackArrays->getOption().matches(options::OPT_fno_stack_arrays))
CmdArgs.push_back("-fstack-arrays");
+ Args.AddLastArg(CmdArgs, options::OPT_fexperimental_loop_fuse,
options::OPT_fno_experimen
@@ -65,6 +65,9 @@ class PipelineTuningOptions {
/// false.
bool LoopInterchange;
+ /// Tuning option to enable/disable loop fuse. Its default value is false.
+ bool LoopFuse;
tarunprabhu wrote:
NIT:
```suggestion
bool LoopFusion;
```
https://github.c
@@ -1671,6 +1671,11 @@ void CompilerInvocationBase::GenerateCodeGenArgs(const
CodeGenOptions &Opts,
else
GenerateArg(Consumer, OPT_fno_loop_interchange);
+ if (Opts.FuseLoops)
+GenerateArg(Consumer, OPT_fexperimental_loop_fuse);
tarunprabhu wrote:
@@ -1991,6 +1996,7 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions
&Opts, ArgList &Args,
(Opts.OptimizationLevel > 1));
Opts.InterchangeLoops =
Args.hasFlag(OPT_floop_interchange, OPT_fno_loop_interchange, false);
+ Opts.FuseLoops = Args
@@ -6869,6 +6869,8 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
options::OPT_fno_unroll_loops);
Args.AddLastArg(CmdArgs, options::OPT_floop_interchange,
options::OPT_fno_loop_interchange);
+ Args.AddLastArg(CmdArgs, op
@@ -204,6 +205,10 @@ static cl::opt
EnableLoopInterchange("enable-loopinterchange", cl::init(false),
cl::Hidden,
cl::desc("Enable the LoopInterchange Pass"));
+static cl::opt EnableLoopFuse("enable-loopfuse", cl::init(false),
tar
@@ -897,6 +897,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
PipelineTuningOptions PTO;
PTO.LoopUnrolling = CodeGenOpts.UnrollLoops;
PTO.LoopInterchange = CodeGenOpts.InterchangeLoops;
+ PTO.LoopFuse = CodeGenOpts.FuseLoops;
tarunprabhu wrote:
@@ -1332,6 +1333,7 @@ runThinLTOBackend(CompilerInstance &CI,
ModuleSummaryIndex *CombinedIndex,
Conf.SampleProfile = std::move(SampleProfile);
Conf.PTO.LoopUnrolling = CGOpts.UnrollLoops;
Conf.PTO.LoopInterchange = CGOpts.InterchangeLoops;
+ Conf.PTO.LoopFuse = CGOpts.
https://github.com/tarunprabhu requested changes to this pull request.
Would you be ok with using `loop-fusion` instead of `loop-fuse`? The former is
a well-recognized name for the transformation. Since the other names of loop
optimizations such as interchange stick to prevalent usage, it would
@@ -4253,6 +4253,10 @@ def floop_interchange : Flag<["-"],
"floop-interchange">, Group,
HelpText<"Enable the loop interchange pass">, Visibility<[ClangOption,
CC1Option, FlangOption, FC1Option]>;
def fno_loop_interchange: Flag<["-"], "fno-loop-interchange">, Group,
HelpTe
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/142686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
The driver side of things looks good to me. Please wait for others to approve
the rest. Thanks.
https://github.com/llvm/llvm-project/pull/150269
___
cfe-commits mailing list
cfe-commits@lists.
https://github.com/tarunprabhu deleted
https://github.com/llvm/llvm-project/pull/150939
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu deleted
https://github.com/llvm/llvm-project/pull/150939
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1541,6 +1541,22 @@ bool CompilerInvocation::createFromArgs(
else
invoc.loweringOpts.setInitGlobalZero(false);
+ // -finit-logical
+ if (const auto *arg =
+ args.getLastArg(clang::driver::options::OPT_finit_logical_EQ)) {
+llvm::StringRef argValue = llv
@@ -172,8 +172,8 @@ void Flang::addCodegenOptions(const ArgList &Args,
options::OPT_flang_deprecated_no_hlfir,
options::OPT_fno_ppc_native_vec_elem_order,
options::OPT_fppc_native_vec_elem_order, options::OPT_finit_global_zero,
- options::OPT_fno_init
@@ -1541,6 +1541,22 @@ bool CompilerInvocation::createFromArgs(
else
invoc.loweringOpts.setInitGlobalZero(false);
+ // -finit-logical
+ if (const auto *arg =
+ args.getLastArg(clang::driver::options::OPT_finit_logical_EQ)) {
+llvm::StringRef argValue = llv
@@ -6960,14 +6960,18 @@ def A_DASH : Joined<["-"], "A-">, Group;
def static_libgfortran : Flag<["-"], "static-libgfortran">,
Group;
// "f" options with values for gfortran.
+// Some of these options are visible for LLVM Flang too.
def fblas_matmul_limit_EQ : Joined<["-"], "f
@@ -74,5 +74,11 @@ ENUM_LOWERINGOPT(SkipExternalRttiDefinition, unsigned, 1, 0)
/// If false, lower to the complex dialect of MLIR.
/// On by default.
ENUM_LOWERINGOPT(ComplexDivisionToRuntime, unsigned, 1, 1)
+
+/// Initialization for logical type
+///-1 : No initializati
@@ -6960,14 +6960,18 @@ def A_DASH : Joined<["-"], "A-">, Group;
def static_libgfortran : Flag<["-"], "static-libgfortran">,
Group;
// "f" options with values for gfortran.
+// Some of these options are visible for LLVM Flang too.
def fblas_matmul_limit_EQ : Joined<["-"], "f
@@ -3706,14 +3706,19 @@ def fopenmp_relocatable_target : Flag<["-"],
"fopenmp-relocatable-target">,
def fnoopenmp_relocatable_target : Flag<["-"], "fnoopenmp-relocatable-target">,
Group, Flags<[NoArgumentUnused, HelpHidden]>,
Visibility<[ClangOption, CC1Option]>;
-def fope
@@ -3706,14 +3706,19 @@ def fopenmp_relocatable_target : Flag<["-"],
"fopenmp-relocatable-target">,
def fnoopenmp_relocatable_target : Flag<["-"], "fnoopenmp-relocatable-target">,
Group, Flags<[NoArgumentUnused, HelpHidden]>,
Visibility<[ClangOption, CC1Option]>;
-def fope
https://github.com/tarunprabhu closed
https://github.com/llvm/llvm-project/pull/149784
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/150269
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -952,6 +954,9 @@ void Flang::ConstructJob(Compilation &C, const JobAction
&JA,
<< A->getSpelling() << A->getValue();
break;
}
+ } else {
+Args.AddLastArg(CmdArgs, options::OPT_fopenmp_simd,
tarunprabhu wrote:
If I understand this c
https://github.com/tarunprabhu commented:
Thanks. The frontend parts of it look fine. I haven't looked too closely at the
core OpenMP changes.
https://github.com/llvm/llvm-project/pull/150269
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
@@ -3706,14 +3706,19 @@ def fopenmp_relocatable_target : Flag<["-"],
"fopenmp-relocatable-target">,
def fnoopenmp_relocatable_target : Flag<["-"], "fnoopenmp-relocatable-target">,
Group, Flags<[NoArgumentUnused, HelpHidden]>,
Visibility<[ClangOption, CC1Option]>;
-def fope
https://github.com/tarunprabhu approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/149417
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
I think I looked at [the other
PR](https://github.com/llvm/llvm-project/pull/149786) first. Thanks for
splitting this into two separate clang and flang PR's.
LGTM, but please wait for someone on the clang side to take a look as well.
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/149786
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
Thanks. LGTM, but please wait for someone on the clang side to take a look as
well.
https://github.com/llvm/llvm-project/pull/149786
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
https://github.com/tarunprabhu approved this pull request.
https://github.com/llvm/llvm-project/pull/146641
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3409,3 +3409,30 @@ StringRef
tools::parseMRecipOption(clang::DiagnosticsEngine &Diags,
return Out;
}
+
+std::string tools::ComplexRangeKindToStr(LangOptions::ComplexRangeKind Range) {
+ switch (Range) {
+ case LangOptions::ComplexRangeKind::CX_Full:
+return "full"
@@ -74,4 +74,26 @@ The ComplexToStandard dialect does still call into libm for
some floating
point math operations, however these don't have the same ABI issues as the
complex libm functions.
+The flang driver option `-fcomplex-arithmetic=` allows you to select whether
+compl
https://github.com/tarunprabhu approved this pull request.
Aside from the slight change to the function names in `CommonArgs.cpp` and an
optional tweak to the documentation text, this looks good to me.
Thank you for PR and the clarifications to my comments.
https://github.com/llvm/llvm-projec
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/146641
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3409,3 +3409,30 @@ StringRef
tools::parseMRecipOption(clang::DiagnosticsEngine &Diags,
return Out;
}
+
+std::string tools::ComplexRangeKindToStr(LangOptions::ComplexRangeKind Range) {
tarunprabhu wrote:
The functions in `CommonArgs.cpp` use a lower-cas
@@ -192,6 +192,31 @@ class CodeGenOptions : public CodeGenOptionsBase {
return getProfileUse() == llvm::driver::ProfileCSIRInstr;
}
+ /// Controls the various implementations for complex division.
tarunprabhu wrote:
I think that it should be moved, but
@@ -609,6 +609,17 @@ class FirOpBuilder : public mlir::OpBuilder, public
mlir::OpBuilder::Listener {
return integerOverflowFlags;
}
+ /// Set ComplexDivisionToRuntimeFlag value for whether complex number
division
+ /// is lowered to a runtime function by this builder
@@ -9,6 +9,7 @@
#ifndef FORTRAN_OPTIMIZER_CODEGEN_CODEGEN_H
#define FORTRAN_OPTIMIZER_CODEGEN_CODEGEN_H
+#include "flang/Frontend/CodeGenOptions.h"
tarunprabhu wrote:
I think the `CodeGenOptions.h` header is included because of the
`ComplexRangeKind` enum. I
@@ -192,6 +192,31 @@ class CodeGenOptions : public CodeGenOptionsBase {
return getProfileUse() == llvm::driver::ProfileCSIRInstr;
}
+ /// Controls the various implementations for complex division.
tarunprabhu wrote:
If this is exactly the same as the e
@@ -629,6 +655,20 @@ static void addFloatingPointOptions(const Driver &D, const
ArgList &Args,
default:
continue;
+case options::OPT_fcomplex_arithmetic_EQ: {
tarunprabhu wrote:
I think this can be moved to `CommonArgs.cpp` as well.
https://gi
https://github.com/tarunprabhu commented:
Thanks. I think we should share the `ComplexRangeKind` enum between `clang` and
`flang`. I am ok with doing it in a separate PR.
https://github.com/llvm/llvm-project/pull/146641
___
cfe-commits mailing list
cf
@@ -484,6 +484,21 @@ static void
parseCodeGenArgs(Fortran::frontend::CodeGenOptions &opts,
}
parseDoConcurrentMapping(opts, args, diags);
+
+ if (const auto *arg =
tarunprabhu wrote:
Could we use a concrete type instead of `auto` here?
https://github.c
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/146641
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3487,7 +3487,8 @@ def fno_experimental_isel : Flag<["-"],
"fno-experimental-isel">, Group;
def fveclib : Joined<["-"], "fveclib=">, Group,
Visibility<[ClangOption, CC1Option, FlangOption, FC1Option]>,
-HelpText<"Use the given vector functions library">,
+HelpText<
@@ -3487,7 +3487,8 @@ def fno_experimental_isel : Flag<["-"],
"fno-experimental-isel">, Group;
def fveclib : Joined<["-"], "fveclib=">, Group,
Visibility<[ClangOption, CC1Option, FlangOption, FC1Option]>,
-HelpText<"Use the given vector functions library">,
+HelpText<
https://github.com/tarunprabhu approved this pull request.
Thanks Tom. I'm fine with merging this.
https://github.com/llvm/llvm-project/pull/144915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
https://github.com/tarunprabhu approved this pull request.
Other than the question about `Flang-RT` vs `compiler-rt` in the
`llvm/CMakeLists`, this looks good to me. Thanks.
https://github.com/llvm/llvm-project/pull/144710
___
cfe-commits mailing list
@@ -653,6 +653,13 @@ if(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD STREQUAL "all")
set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD ${LLVM_ALL_EXPERIMENTAL_TARGETS})
endif()
+if("flang" IN_LIST LLVM_ENABLE_PROJECTS AND
+ "AArch64" IN_LIST LLVM_TARGETS_TO_BUILD AND
+ NOT "compiler-rt" IN_
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/144710
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
Thanks for the fix @kiranchandramohan. I didn't spot the issue with
`llvm-profdata`
https://github.com/llvm/llvm-project/pull/142892
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
tarunprabhu wrote:
There is a similar build failure
[here](https://github.com/llvm/llvm-project/pull/143603) that seems to be even
older. I don't think these are related.
https://github.com/llvm/llvm-project/pull/142892
___
cfe-commits mailing list
c
https://github.com/tarunprabhu closed
https://github.com/llvm/llvm-project/pull/142892
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
Thanks. I'll merge this tomorrow morning (my time), so I can keep an eye on the
buildbots, just in case.
https://github.com/llvm/llvm-project/pull/142892
___
cfe-commits mailing list
cfe-commi
https://github.com/tarunprabhu approved this pull request.
Other than the one comment, the frontend related parts LGTM, but please wait
for someone more familiar with the OpenMP side of things.
https://github.com/llvm/llvm-project/pull/143441
___
cfe-
@@ -88,6 +88,44 @@ void fir::setTuneCPU(mlir::ModuleOp mod, llvm::StringRef
cpu) {
mod->setAttr(tuneCpuName, mlir::StringAttr::get(ctx, cpu));
}
+static constexpr const char *amdgpuIgnoreDenormalModeName =
+"fir.amdgpu.ignore.denormal.mode";
+void fir::setAmdgpuIgnoreDe
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/143441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/143508
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu closed
https://github.com/llvm/llvm-project/pull/143418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu commented:
Thanks Tom. Since this has been enabled for `fc1` as well, could you add a test
to ensure that it is accepted by `fc1` as well. Just one should be fine. We
don't have to check everything in both cases.
https://github.com/llvm/llvm-project/pull/143508
_
@@ -58,10 +58,24 @@ void setTargetCPU(mlir::ModuleOp mod, llvm::StringRef cpu);
/// Get the target CPU string from the Module or return a null reference.
llvm::StringRef getTargetCPU(mlir::ModuleOp mod);
+// Setters and Getters for atomic control options
+void setAmdgpuIgnoreD
@@ -2911,8 +2911,13 @@ static void genAtomicUpdateStatement(
if (rightHandClauseList)
genOmpAtomicHintAndMemoryOrderClauses(converter, *rightHandClauseList,
hint,
memoryOrder);
+ auto module = firOpBuilder.getModule();
-
@@ -53,6 +53,11 @@ class TargetOptions {
/// Print verbose assembly
bool asmVerbose = false;
+
+ /// Atomic Control Options for AMD GPU
tarunprabhu wrote:
Nit
```suggestion
/// Atomic control options for AMD GPU
```
https://github.com/llvm/llvm-projec
@@ -58,10 +58,24 @@ void setTargetCPU(mlir::ModuleOp mod, llvm::StringRef cpu);
/// Get the target CPU string from the Module or return a null reference.
llvm::StringRef getTargetCPU(mlir::ModuleOp mod);
+// Setters and Getters for atomic control options
tarun
https://github.com/tarunprabhu commented:
Thanks for this.
Since you have added both `FlangOption` and `FC1Option` in `Options.td`, could
you add a test that checks that the option is handled by the main driver as
well as `fc1`. One that simply checks that the option gets passed down to `fc1`
@@ -54,6 +54,20 @@ def FlagsAttr : OpenMP_Attr<"Flags", "flags"> {
let assemblyFormat = "`<` struct(params) `>`";
}
+//===--===//
+// AtomicControlAttr
+//===-
@@ -88,6 +88,46 @@ void fir::setTuneCPU(mlir::ModuleOp mod, llvm::StringRef
cpu) {
mod->setAttr(tuneCpuName, mlir::StringAttr::get(ctx, cpu));
}
+static constexpr const char *amdgpuIgnoreDenormalModeName =
+"fir.amdgpu.ignore.denormal.mode";
+void fir::setAmdgpuIgnoreDe
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/143441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
Thanks for the changes, Cameron. LGTM.
https://github.com/llvm/llvm-project/pull/143418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
@@ -2636,6 +2636,11 @@ void
ModuleImport::processFunctionAttributes(llvm::Function *func,
funcOp.setTargetFeaturesAttr(
LLVM::TargetFeaturesAttr::get(context, attr.getValueAsString()));
+ if (llvm::Attribute attr = func->getFnAttribute("reciprocal-estimates");
+
@@ -1549,6 +1549,9 @@ LogicalResult
ModuleTranslation::convertOneFunction(LLVMFuncOp func) {
if (auto tuneCpu = func.getTuneCpu())
llvmFunc->addFnAttr("tune-cpu", *tuneCpu);
+ if (auto reciprocalEstimates = func.getReciprocalEstimates())
tarunprabhu wr
@@ -0,0 +1,27 @@
+! Test that -mrecip[=] works as expected.
+
tarunprabhu wrote:
Since you have added both `FlangOption` and `FC1Option` in `Options.td`, could
we test that the option is recognized by the main driver as well, not just
`-fc1`?
https://github.co
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
+
+; CHECK-LABEL: llvm.func @reciprocal_estimates()
+; CHECK-SAME: reciprocal_estimates = "all"
+define void @reciprocal_estimates() #0 {
+ ret void
+}
+
+attributes #0 = { "reciprocal-estimat
@@ -1549,6 +1549,9 @@ LogicalResult
ModuleTranslation::convertOneFunction(LLVMFuncOp func) {
if (auto tuneCpu = func.getTuneCpu())
llvmFunc->addFnAttr("tune-cpu", *tuneCpu);
+ if (auto reciprocalEstimates = func.getReciprocalEstimates())
tarunprabhu wr
@@ -2636,6 +2636,11 @@ void
ModuleImport::processFunctionAttributes(llvm::Function *func,
funcOp.setTargetFeaturesAttr(
LLVM::TargetFeaturesAttr::get(context, attr.getValueAsString()));
+ if (llvm::Attribute attr = func->getFnAttribute("reciprocal-estimates");
+
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/143418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -56,6 +56,9 @@ class CodeGenOptions : public CodeGenOptionsBase {
// The prefered vector width, if requested by -mprefer-vector-width.
std::string PreferVectorWidth;
+ // List of reciprocal estimate sub-options.
tarunprabhu wrote:
Should this be a doc
@@ -3189,3 +3189,144 @@ StringRef
tools::ParseMPreferVectorWidthOption(clang::DiagnosticsEngine &Diags,
return Value;
}
+
+// This is a helper function for validating the optional refinement step
+// parameter in reciprocal argument strings. Return false if there is an erro
https://github.com/tarunprabhu commented:
Thanks for this. Just some minor comments.
https://github.com/llvm/llvm-project/pull/143418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu approved this pull request.
https://github.com/llvm/llvm-project/pull/142800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -238,6 +238,12 @@
#define LLVM_PREFETCH(addr, rw, locality)
#endif
+#if __has_attribute(uninitialized)
+#define LLVM_ATTRIBUTE_UNINITIALIED __attribute__((uninitialized))
tarunprabhu wrote:
Spelling:
```suggestion
#define LLVM_ATTRIBUTE_UNINITIALIZED __a
https://github.com/tarunprabhu requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/142800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
> I had 1 minor objection, see my concern on the `uninitialized` attribute
> removal.
Would it be simpler just to initialize the variable before use? I assume that
the attribute is present to eliminate compiler warnings about uninitialized
variables being passed by referenc
https://github.com/tarunprabhu approved this pull request.
Thanks for the changes, Cameron.
Could you take a look at the [failing
buildkite](https://github.com/llvm/llvm-project/actions/runs/15493623574/job/43624895590?pr=142800)
and see if it is something relevant? It seems to be a Windows b
1 - 100 of 434 matches
Mail list logo
