search for: noimplicitfloat

...1. The outlining itself will prevent the undesired code motion today, but in the future we'll have IPO transformations that will need to be specifically taught to avoid moving FP operations into these outlined functions. 2. The outlined functions will need to be marked with noinline and also noimplicitfloat. In fact, all functions using the constrained intrinsics might need to be marked with noimplicitfloat. The above-mentioned restrictions on IPO passes might be conditioned on the noimplicitfloat attribute. -Hal Although this approach prevents from moving instructions, it does not prevent from m...

...llimport | Dllexport | External_weak | Ghost + | Common + | Linker_private end module Visibility = struct @@ -79,6 +84,15 @@ | Nest | Readnone | Readonly + | Noinline + | Alwaysinline + | Optforsize + | Stackprotect + | Stackprotectreq + | Nocapture + | Noredzone + | Noimplicitfloat + | Naked end module Icmp = struct diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Sun Dec 27 11:38:15 2009 -0800 @@ -82,13 +82,...

...XMM) register arguments is stored in %al, and the code normally generated for variadic functions (in the absence of -no-implicit-float) includes a guard around the XMM spill code that checks for %al != 0. Therefore I believe it would be "in the spirit" of -no-implicit-float to remove the NoImplicitFloatOps check from the following: X86ISelLowering.cpp : get64BitArgumentXMMs() if (isSoftFloat || NoImplicitFloatOps || !Subtarget.hasSSE1()) // Kernel mode asks for SSE to be disabled, so there are no XMM argument...

...| Linker_private > end > > module Visibility = struct > @@ -79,6 +84,15 @@ > | Nest > | Readnone > | Readonly > + | Noinline > + | Alwaysinline > + | Optforsize > + | Stackprotect > + | Stackprotectreq > + | Nocapture > + | Noredzone > + | Noimplicitfloat > + | Naked > end > > module Icmp = struct > diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli > --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Fri Dec 25 17:35:09 2009 -0800 > +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Sun Dec 27 11...

...Re: [llvm-dev] variadic functions on X86_64 should (conditionally) save XMM regs even if -no-implicit-float Hello Apologies to hijack old thread, but it seems to receive no response. It seems we're having 2 problems here and all of them are x86 specific. Here is quick overview of the problem: noimplicitfloat should in theory prevent compiler to generate floating point operations by itself. Currently it's used during optimizations and codegen as follows: - It inhibits some optimizations like vectorization - It is used to determine optimal set of operations for things like inlined memcpy / memset...

Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other related facilities. Problem On many processors use of non-default floating mode requires

On 9/7/20 10:56 AM, Nicolai Hähnle wrote: > Hi Johannes and Atmn, > > On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  > In any case, please explain the intended behavior of the attribute and >>  > the metadata upon inlining. >> >> The attribute will be attached to the caller upon

...virtually all attributes _allow_ > program transforms instead. The only other example I can think of > right now is "convergent". An incomplete list of function attributes that disable transformations (not actually checked but I expect them too):   cold, convergent, noduplicate, noimplicitfloat, nomerge, noinline,   nobuiltin, null_pointer_is_valid, optsize, optnone, returns_twice,   "thunk" Similarly there are parameter attributes that prevent transformations. >>  > Assuming the simple flip of polarity from the previous paragraph, what >>  > is the diff...

...tect || I->getKindAsEnum() == Attribute::StackProtectReq || I->getKindAsEnum() == Attribute::StackProtectStrong || + I->getKindAsEnum() == Attribute::SafeStack || I->getKindAsEnum() == Attribute::NoRedZone || I->getKindAsEnum() == Attribute::NoImplicitFloat || I->getKindAsEnum() == Attribute::Naked || diff --git a/lib/Target/CppBackend/CPPBackend.cpp b/lib/Target/CppBackend/CPPBackend.cpp index f610fbb..5589f69 100644 --- a/lib/Target/CppBackend/CPPBackend.cpp +++ b/lib/Target/CppBackend/CPPBackend.cpp @@ -510,6 +510,7 @@ void CppWriter::p...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

.../X86/X86ISelLowering.cpp (revision 72159) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@ -117,15 +117,18 @@ setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Promote); setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Expand); } else { - if (!UseSoftFloat && !NoImplicitFloat && X86ScalarSSEf64) { + if (!UseSoftFloat && X86ScalarSSEf64) { // We have an impenetrably clever algorithm for ui64->double only. setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Custom); - - // We have faster algorithm for ui32->single only. - se...