search for: mfpmath

...e, the only alternatives we have at the moment is to either use NEON for everything or nothing. It would be good to have an option to use NEON for integer arithmetic and VFP for FP if the user requires IEEE compliance.. > P.S. Looking at gcc's man page, gcc seems to use -mfpu for ARM and -mfpmath for x86. Do we use -mfpmath for both? We already support -mfpmath=vfp/neon in Clang, but it's bogus. My proposal is to make it count. The best way I can think of is to let -mfpmath=vfp *disable* only FP NEON and -mfpmath=neon *enable* only FP NEON, both orthogonal from integer math. Examples...

On 2011-02-12 12:34, David Given wrote: ... > You might want to look at the generated machine code to see how they > differ. If this *is* the problem, you can tell gcc to use a particular > instruction set with -mfpmath=386 or -mfpmath=sse. I think you mean -mfpmath=387, instead. :) Btw, this option is also not supported by clang... any idea how it could be implemented, if at all?

...emantics query would return true if: !(isDarwin OR ARMISA >= v8 OR fpMath == NEON) and then we need to teach people to use -mfpu=neon ;) I think this more-or-less matches what you've proposed. Is that right? -Hal P.S. Looking at gcc's man page, gcc seems to use -mfpu for ARM and -mfpmath for x86. Do we use -mfpmath for both? ----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "James Molloy" <James.Molloy at arm.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvm-dev...

On 22 March 2016 at 11:34, James Molloy <James.Molloy at arm.com> wrote: > I don’t think this part is right. The denormal flag would have to be set by > whatever code generates the FP instruction, which would be Clang’s codegen > layer. So the if (Darwin) would be there, not in TTI. Right, I meant the information to set/not set would be in TTI, not the actual setting. I don't

...1 at 1:06 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 2011-02-12 12:34, David Given wrote: >> You might want to look at the generated machine code to see how they >> differ. If this *is* the problem, you can tell gcc to use a particular >> instruction set with -mfpmath=386 or -mfpmath=sse. > > I think you mean -mfpmath=387, instead. :) > > Btw, this option is also not supported by clang... any idea how it could > be implemented, if at all? Shouldn't be that hard for 32-bit x86 since -mattr=-sse already works when passed to llc (but not clang)...

...ing to SSE (which most compiler software these days does because 387 instructions are horrible), this might explain the results you get. You might want to look at the generated machine code to see how they differ. If this *is* the problem, you can tell gcc to use a particular instruction set with -mfpmath=386 or -mfpmath=sse. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "I have a mind like a steel trap. It's rusty and full of dead mice." │ --- Anonymous, on rasfc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:...

I have a very simple test case on Windows that shows some surprising behavior. This doesn't seem to be a problem on Linux. The example is: #include <stdio.h> #include <math.h> double heat(double Pr) { return pow(Pr, 0.33); } int main(int argc, char **argv) { double Nu = heat(291.00606180486119); printf("%.20f\n", Nu); } I've tested with MinGW's gcc.exe

...is to either > use NEON for everything or nothing. It would be good to have an option > to use NEON for integer arithmetic and VFP for FP if the user requires > IEEE compliance. In GCC, this is -mfpu=neon. > > P.S. Looking at gcc's man page, gcc seems to use -mfpu for ARM and -mfpmath > > for x86. Do we use -mfpmath for both? > > We already support -mfpmath=vfp/neon in Clang, but it's bogus. My > proposal is to make it count. > > The best way I can think of is to let -mfpmath=vfp *disable* only FP > NEON and -mfpmath=neon *enable* only FP NEON, both...

...I have two computers with the almost identical hardware (P4 Northwood CPU, i875 chipset, 2GB DDR400 RAM) and identical Linux OS. I have the latest version of libgoto for this CPU installed on both boxes (libgoto_northwood32p-r1.00.so) and I am using gcc compiler flags "-O2 -march=pentium4 -mfpmath=sse -msse2" to enable use of SSE2 extensions. With one computer that works perfectly, while on the other one "make check" constantly fails on lm-test. If I remove "-mfpmath=sse -msse2" part from the gcc flags then all checks pass on the second computer too. Any hints on...

Olivier Tristan <o.tristan at uvi.net> ?????(?) ? ????? ?????? Fri, 21 Mar 2014 22:41:00 +0400: > Check with -mfpmath=387 to be sure that x87 FPU code is used and not some > SSE optim made by GCC I added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac Still the result is different from SSE version. --------------- MSVS adds two instructions to the generated code after the patch: fld DWORD PTR...

wxRuby 0.6.0 has been released and is now available for download from RubyForge at http://wxruby.rubyforge.org/ This release includes binary builds for Max OS X and MS Windows. Changes in this release include: * Additional widget support in XRC (thanks to Marshall Elfstrand) * Addition of wxScrollbar (thanks to Hans Harmon of Pinnacle Technologies Inc) * Addition of wxGrid event handlers (thanks

...ngs # PROC = $(shell uname -m) INSTALL = install CC = gcc INCLUDE = -I$(ASTERISK_INCLUDE_DIR) LIBS = -ldl -lpthread -lm DEBUG := -g CFLAGS = -pipe -Wall -Wmissing-prototypes -Wmissing-declarations $(DEBUG) $(INCLUDE) -D_REENTRANT -D_GNU_SOURCE #CFLAGS += -O2 #CFLAGS += -O3 -march=pentium3 -msse -mfpmath=sse,387 -ffast-math # PERF: below is 10% faster than -O2 or -O3 alone. #CFLAGS += -O3 -ffast-math -funroll-loops # below is another 5% faster or so. CFLAGS += -O3 -ffast-math -funroll-all-loops -fprefetch-loop-arrays -fsingle-precision-constant # this is fun for PPC #CFLAGS += -mcpu=7450 -faltivec...

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

Trying to build today's svn on fc5, gcc-4.1.0,amd64: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I.. -I/usr/include -O2 -fPIC -funswitch-loops -ftree-loop-linear -march=k8 -ftree-vectorize -pipe -mfpmath=sse -frename-registers -O3 -msse -MT nb_celp.lo -MD -MP -MF .deps/nb_celp.Tpo -c nb_celp.c -fPIC -DPIC -o .libs/nb_celp.o nb_celp.c: In function 'nb_encode': nb_celp.c:442: error: 'EncState' has no member named 'frame' make[2]: *** [nb_celp.lo] Error 1 make[2]: Leaving di...

Hal, James, My plan to disable vectorization on NEON FP had two steps: 1. Create the infrastructure to detect unsafe FP maths and force NEON FP via fast-math. 2. Use -mfpmath=neon/sse to fine-tune the flags even further, but this needs a lot of work in IR. The expected behaviour is to have most performance with least options, but with correctness in mind. So, we can't vectorize FP loops without either -ffast-math or -mfpmath=neon, but we want to tell the users that...

...failures (i.e. different results) if intermediates use different precision, if the test reference is calculated assuming rounding all intermediates to a certain length between each step. The solution: to get the same results on 32-bit as on 64-bit, you need to build R with these extra gcc flags: -mfpmath=sse -msse2. As explained in https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/x86-Options.html#x86-Options the -mfpmath=sse is the default for x86-64 but not for i686. As of r77719 we have made sse the default on Windows and now we get consistent results on 32-bit and 64-bit, including the round() edge...

Do anybody could compile app_conference on x86_64??? I tryied with two versions of app_conference and got the same problem on compiling: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared recompile with -fPIC app_conference.o: could not read symbols: Bad value" ENVIRONMENT:

...current CRAN policy doesn't allow the C++11 standard, > it would still be useful to document this, perhaps in the Writing R > Extensions manual. > > - Hsiu-Khuern Hello, Hsiu-Khuern. All the times I have built, I've passed -std-gnu++11. Specifically, I pass: -march=native -O3 -mfpmath=sse -std=gnu++11 -msse2avx -mavx256-split-unaligned-load -mavx256-split-unaligned-store -mvzeroupper --param l1-cache-line-size=64 --param l1-cache-size=64 --param l2-cache-size=256. I live with the repeated warnings that it isn't needed for gcc, but I know it takes as I see the same string (gn...

G'day all, I have daily scripts running to install the patched version of the current R version and the development version of R on my linux box (Ubuntu 18.04.4 LTS). The last development version that was successfully compiled and installed was "R Under development (unstable) (2020-01-25 r77715)" on 27 January. Since then the script always fails as a regression test seems to fail.

...addsd .LC1, %xmm0 movsd %xmm0, -8(%ebp) fldl -8(%ebp) LLVM Backend is using xmms it involves a lot of register moves. llc has one option -mcpu=686, where output does not use xmm but it disables some other instructions also. Is there any fine grain optimization flag like ( -mfpmath = 387 which is present in gcc) which would just instruction backend to use fpstack instead of SSE instructions and still not limit the instructions Thanks --Kapil . -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attach...