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
@@ -3167,3 +3167,29 @@ void tools::handleInterchangeLoopsArgs(const ArgList
&Args,
options::OPT_fno_loop_interchange, EnableInterchange))
CmdArgs.push_back("-floop-interchange");
}
+
+std::optional tools::ParseMPreferVectorWidthOption(
+clang::Diagno
@@ -3167,3 +3167,29 @@ void tools::handleInterchangeLoopsArgs(const ArgList
&Args,
options::OPT_fno_loop_interchange, EnableInterchange))
CmdArgs.push_back("-floop-interchange");
}
+
+std::optional tools::ParseMPreferVectorWidthOption(
+clang::Diagno
@@ -3167,3 +3167,29 @@ void tools::handleInterchangeLoopsArgs(const ArgList
&Args,
options::OPT_fno_loop_interchange, EnableInterchange))
CmdArgs.push_back("-floop-interchange");
}
+
+std::optional tools::ParseMPreferVectorWidthOption(
+clang::Diagno
@@ -270,6 +270,11 @@ void handleVectorizeLoopsArgs(const llvm::opt::ArgList
&Args,
/// Enable -fslp-vectorize based on the optimization level selected.
void handleVectorizeSLPArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs);
+
tarunprabhu wrote:
Thanks for the fix and the explanation. I will try this PR out, but it might
take me a day or two. Do you have merge access? If not, I will merge it if
everything passes for me.
https://github.com/llvm/llvm-project/pull/142892
___
@@ -270,6 +270,12 @@ void handleVectorizeLoopsArgs(const llvm::opt::ArgList
&Args,
/// Enable -fslp-vectorize based on the optimization level selected.
void handleVectorizeSLPArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs);
+
@@ -3167,3 +3167,30 @@ void tools::handleInterchangeLoopsArgs(const ArgList
&Args,
options::OPT_fno_loop_interchange, EnableInterchange))
CmdArgs.push_back("-floop-interchange");
}
+
+void tools::ParseMPreferVectorWidthOption(clang::DiagnosticsEngine &Di
@@ -270,6 +270,12 @@ void handleVectorizeLoopsArgs(const llvm::opt::ArgList
&Args,
/// Enable -fslp-vectorize based on the optimization level selected.
void handleVectorizeSLPArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs);
+
tarunprabhu wrote:
> I'm very sorry for this trouble.I'll check carefully and fix it before
> submitting again.
Happens to all of us. As a reviewer, I should have spotted this before
approving it. Let's both try to get it right the second time around :-)
https://github.com/llvm/llvm-project/p
tarunprabhu wrote:
> > LGTM, though, I think we'd better reuse the code from `Clang.cpp`.
> > `flangFrontend` already depends on `clangDriver`, so we just need to export
> > `ParseMRecip` and `getRefinementStep` from `clangDriver` (and probably
> > replace their `Driver` argument with a `Diagn
https://github.com/tarunprabhu approved this pull request.
Thanks Abid. LGTM.
https://github.com/llvm/llvm-project/pull/140556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
@mcinally,
It looks like the buildbot failure is because a test is written expecting a
single attribute, but two are present, although the attribute being checked for
is present.
https://github.com/llvm/llvm-project/pull/142073
_
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/140556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu created
https://github.com/llvm/llvm-project/pull/142159
Reverts llvm/llvm-project#136098
>From b9503fe262c416111ee77be30767a791cf750fb8 Mon Sep 17 00:00:00 2001
From: Tarun Prabhu
Date: Fri, 30 May 2025 08:22:15 -0600
Subject: [PATCH] =?UTF-8?q?Revert=20"Add=20I
https://github.com/tarunprabhu closed
https://github.com/llvm/llvm-project/pull/142073
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
@fanju110
The PR caused some buildbot failures, so I have
[reverted](https://github.com/llvm/llvm-project/commit/597340b5b666bdee2887f56c111407b6737cbf34)
it. You can see the error
[here](https://lab.llvm.org/buildbot/#/builders/203/builds/12089/steps/7/logs/stdio).
htt
@@ -0,0 +1,17 @@
+! RUN: env FCC_OVERRIDE_OPTIONS="#+-Os +-Oz +-O +-O3 +-Oignore +a +b +c xb Xa
Omagic ^-### " %flang -target x86_64-unknown-linux-gnu %s -O2 b -O3 2>&1 |
FileCheck %s
tarunprabhu wrote:
Should this also be `--target`?
```suggestion
! RUN: env
https://github.com/tarunprabhu closed
https://github.com/llvm/llvm-project/pull/142159
___
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/136098
___
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
https://github.com/llvm/llvm-project/pull/142073
___
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 for the changes, Abid. Regarding my suggestions in the documentation,
feel free to incorporate or discard them as you see fit.
I'll leave it you and @kiranchandramohan to decide what the name of the
environment variable should be.
Other than
@@ -614,3 +614,30 @@ nvfortran defines `-fast` as
- `-Mcache_align`: there is no equivalent flag in Flang or Clang.
- `-Mflushz`: flush-to-zero mode - when `-ffast-math` is specified, Flang will
link to `crtfastmath.o` to ensure denormal numbers are flushed to zero.
+
+
+#
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/140556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
> > Seems ok now: "Changes can be cleanly merged."
> > If it's still not available, I may have messed something up on my side.
> > I'll review the GitHub docs to see if I missed something...
>
> It's probably fine, but I'd like to give the buildkites a chance to finish
> bef
tarunprabhu wrote:
> Seems ok now: "Changes can be cleanly merged."
>
> If it's still not available, I may have messed something up on my side. I'll
> review the GitHub docs to see if I missed something...
It's probably fine, but I'd like to give the buildkites a chance to finish
before I mer
tarunprabhu wrote:
> @tarunprabhu Would you mind mashing the "Merge" button? It looks like getting
> commit access approval is taking longer than expected.
You may need to rebase before I can merge.
https://github.com/llvm/llvm-project/pull/141380
__
@@ -126,6 +127,8 @@ struct MLIRToLLVMPassPipelineConfig : public
FlangEPCallBacks {
bool NoSignedZerosFPMath =
false; ///< Set no-signed-zeros-fp-math attribute for functions.
bool UnsafeFPMath = false; ///< Set unsafe-fp-math attribute for functions.
+ std::string
tarunprabhu wrote:
> > @fanju110, Thanks for seeing this through!
>
> Hi @tarunprabhu , If everything looks good, could you please merge this PR at
> your convenience (I don't have merge rights)? Thank you!
It looks like you need to run `clang-format` on some of the code. See
[here](https://g
tarunprabhu wrote:
> > Does `CCC_OVERRIDE_OPTIONS` expands to Clang Compiler Commandline Override
> > Options? If so `FCC_OVERRIDE_OPTIONS` expanding to Fortran Compiler
> > Commandline Override Options seems the right replacement.
> > If `CCC_OVERRIDE_OPTIONS` expands to Clang C Compiler Overr
@@ -0,0 +1,12 @@
+! RUN: env FCC_OVERRIDE_OPTIONS="#+-Os +-Oz +-O +-O3 +-Oignore +a +b +c xb Xa
Omagic ^-### " %flang -target x86_64-unknown-linux-gnu %s -O2 b -O3 2>&1 |
FileCheck %s
tarunprabhu wrote:
We may also want to have a test for the interaction of th
@@ -614,3 +614,28 @@ nvfortran defines `-fast` as
- `-Mcache_align`: there is no equivalent flag in Flang or Clang.
- `-Mflushz`: flush-to-zero mode - when `-ffast-math` is specified, Flang will
link to `crtfastmath.o` to ensure denormal numbers are flushed to zero.
+
+
+#
https://github.com/tarunprabhu approved this pull request.
Thanks for the all the changes. LGTM.
https://github.com/llvm/llvm-project/pull/141380
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
+
+; CHECK-LABEL: llvm.func @prefer_vector_width()
+; CHECK: prefer_vector_width = "128"
tarunprabhu wrote:
Thanks for the update and clarification.
https://github.com/llvm/l
https://github.com/tarunprabhu closed
https://github.com/llvm/llvm-project/pull/141036
___
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.
@fanju110, Thanks for seeing this through!
https://github.com/llvm/llvm-project/pull/136098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
+
+; CHECK-LABEL: llvm.func @prefer_vector_width()
+; CHECK: prefer_vector_width = "128"
tarunprabhu wrote:
Oh, does `CHECK-LABEL` allow one to continue checking on the same l
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
+
+; CHECK-LABEL: llvm.func @prefer_vector_width()
+; CHECK: prefer_vector_width = "128"
tarunprabhu wrote:
Should this be `CHECK-SAME`? I assume that you intend to match
`pr
https://github.com/tarunprabhu approved this pull request.
Thanks. Any cleanup of this code is helpful.
https://github.com/llvm/llvm-project/pull/141036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
@@ -309,6 +309,20 @@ static void
parseCodeGenArgs(Fortran::frontend::CodeGenOptions &opts,
for (auto *a : args.filtered(clang::driver::options::OPT_fpass_plugin_EQ))
opts.LLVMPassPlugins.push_back(a->getValue());
+ // -mprefer_vector_width option
+ if (const llvm::opt
https://github.com/tarunprabhu edited
https://github.com/llvm/llvm-project/pull/141380
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tarunprabhu requested changes to this pull request.
Thanks for this. I second @jeanPerier's request for an MLIR test
https://github.com/llvm/llvm-project/pull/141380
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/tarunprabhu approved this pull request.
LGTM. Thanks!
https://github.com/llvm/llvm-project/pull/140182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
Is this doing a lot that is similar to #140533?
https://github.com/llvm/llvm-project/pull/140544
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
> The `FCC_OVERRIDE_OPTIONS` seemed like the most obvious name to me but I am
> open to other ideas.
Thanks Abid. Perhaps `FFC_OVERRIDE_OPTIONS`? It has a similar correspondence to
`CCC_OVERRIDE_OPTIONS` as `FCFLAGS` does to `CCFLAGS`. But I don't have a
strong opinion on
https://github.com/tarunprabhu approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/140533
___
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/140182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 388 matches
Mail list logo
