search for: ffix

I'm adding support for -ffixed-<reg> <http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for suppor...

On 10/2/2012 9:36 AM, 陳韋任 (Wei-Ren Chen) wrote: > On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote: >> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should >> do it in such a way that other targets get the support as well by default or if >> a given target back-end should have to explicitly opt-in for support. > What "-ffixed-<reg>" does? > > Regards, >...

Hi I am trying to register shadow a global variable using -ffixed option in llvm-gcc. I am able to accomplish this using gcc however llvm-gcc seems to ignore this option and generate code using the register. command line: >gcc -Wall -m64 -O3 -pthread -ftls-model=initial-exec -ffixed-r12 test.c -o test >objdump -d ./test | grep r12 >llvm-gcc -W...

On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote: > I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should > do it in such a way that other targets get the support as well by default or if > a given target back-end should have to explicitly opt-in for support. What "-ffixed-<reg>" does? Regards, chenwj -- Wei-Ren Chen (陳...

...There probably are more like this. Thanks for pointing that out. We will investigate and extend our design. > > Why did you decide to use global metadata here? For AArch64, we use a target feature instead, to implement roughly equivalent functionality (the reserve-x18 feature, to implement -ffixed-x18). > Making a global register declaration have side-effects never made sense, IMO; on the surface, it's using variable declaration syntax, but in reality it's actually changing the ABI rules for the whole file. > I would prefer to support -ffixed-r4, and never allow global regist...

...ent this in > LLVM IR with named metadata (http://llvm.org/docs/LangRef.html# > namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up > by the code generator, installed as preallocated registers (Jakob would be the > one to ask how best to do this). -ffixed-<reg> and global register seems do the same thing, they both reserve register from being used by the compiler. IIRC, you don't want to add global register support before. If so, why would you think -ffixed-<reg> is O.K.? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems La...

On Oct 2, 2012, at 7:23 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote: > I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support. It would be great to have this as a target-indepentent (well, obviously the specific registe...

> From the GCC manual (http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/ > Code-Gen-Options.html#index-ffixed-2267) > > -ffixed-reg > > Treat the register named reg as a fixed register; generated code should > never refer to it (except perhaps as a stack pointer, frame pointer or in > some other fixed role). > > reg must be the name of a register. The register n...

...IR with named metadata (http://llvm.org/docs/LangRef.html# >> namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up >> by the code generator, installed as preallocated registers (Jakob would be the >> one to ask how best to do this). > > -ffixed-<reg> and global register seems do the same thing, they both > reserve register from being used by the compiler. IIRC, you don't want > to add global register support before. If so, why would you think > -ffixed-<reg> is O.K.? I'm not opposed to implementing support...

...Darwin_9_x86 lib);\ done [ -d bin.Darwin_9_x86 ] || mkdir bin.Darwin_9_x86 cd bin.Darwin_9_x86; make -f /Users/howarth/xplor-nih-2.21/fortlib/libfft/Makefile \ ARCH=Darwin_9_x86 SRCDIR=/Users/howarth/xplor-nih-2.21/fortlib/libfft/ ARCHDEP=TRUE lib llvm-gfortran -c -O4 -fPIC -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dsint.f llvm-gfortran -c -O4 -fPIC -ffast-math -msse4 -ffixed-line-length-120 -fno-second-underscore -DZOMPLEX /Users/howarth/xplor-nih-2.21/fortlib/libfft/dsinti.f llvm-gfortran -c -O4 -fPIC -ff...

...==================== --- lang-specs.h (revision 57986) +++ lang-specs.h (working copy) @@ -14,7 +14,9 @@ "cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN % (cpp_options) \ %{E|M|MM:%(cpp_debug_options)}\ %{!M:%{!MM:%{!E: -o %|.f |\n\ - f951 %|.f %{!ffree-form:-ffixed-form} %(cc1_options) %{J*} %{I*}\ + f951 %|.f %{!ffree-form:-ffixed-form} %(cc1_options) \ + %<Wformat %<Wformat-security %<Wno-format-extra-args %<Wno-format- zero-length %<Wno-nonull \ + %{J*} %{I*}\ "/* LLVM LOCAL */" \ %(llvm_options) \...

....html#Global-Register-Variables Draft Patch: https://reviews.llvm.org/D56005 A Note on r7, r11 and r9 ---------------------------------- Whilst generally considered allocatable, these registers can on occasion be reserved for other purposes. As frame pointers, in the case of r7, and r11, and via -ffixed-r9 (or -frwpi), in the case of r9. The attached patches do not currently provide any mitigations against these cases. Options could range from disallowing these registers entirely, to throwing warnings or trying to catch and error in the correct scenarios (e.g. usage -ffixed-r9 when r9 is declar...

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

...be clobbered anywhere in code on Linux. The Wine code sets up this register before passing control over to the Windows executable code, but whenever the Windows code calls a function implemented in Wine, this register ends up clobbered. The initial solution is to compile Wine itself with the -ffixed-x18 flag, to treat the x18 register as reserved within Wine, so that no compiler generated code touches it. This works fine as long as Wine makes no calls to other libraries from the outside Linux distribution - but e.g. as soon as any glibc function is called, it can end up clobbered again....

Getting this warning compiling on an alpha, is it a problem? 2.4.15-pre4 gcc -D__KERNEL__ -I/usr/users/donjr/linux-2.4.15-pre4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -DEXPORT_SYMTAB -c journal.c journal.c: In function `journal_init_inode': journal.c:758: warning: long long int format, loff_t arg (arg 5) rm -f jbd.o

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

...sed to hold the TEB pointer. When calling Wine builtin functions from the Windows native code, the Wine builtin functions can clobber the x18 register, as the Wine code is built for the ABI and calling conventions used on Linux. This part is easy to work around by compiling Wine with the flag -ffixed-x18, which makes the compiler treat this register as reserved, avoiding clobbering it. However, as the Wine code may end up calling functions in the surrounding host environment (mainly the libc, but potentially also other feature libraries that are used), and these libraries have not been bu...

Hi, How can I reserve an ARM register for only a part of the code? Example: lets say I have 3 functions, A(), B() and C(). I want to prohibit compiler from using a register (lets say X9 in ARM 64) in function C() only. I think that by AArch64RegisterInfo::getReservedRegs function, a register can be reserved for the whole program. But, I need to reserve for only part of the code. Can I

...inc b/klibc/arch/parisc/Makefile.inc index 980a543..4fddf5f 100644 --- a/klibc/arch/parisc/Makefile.inc +++ b/klibc/arch/parisc/Makefile.inc @@ -14,6 +14,3 @@ ARCHOBJS = \ ARCHOOBJS = $(patsubst %o,%.lo,%(ARCHOBJS)) archclean: - -arch/$(ARCH)/syscall.o: arch/$(ARCH)/syscall.c - $(CC) $(CFLAGS) -ffixed-r20 -c -o $@ $< diff --git a/klibc/arch/parisc/syscall.S b/klibc/arch/parisc/syscall.S new file mode 100644 index 0000000..a4f26f5 --- /dev/null +++ b/klibc/arch/parisc/syscall.S @@ -0,0 +1,36 @@ +/* + * arch/parisc/syscall.S + * + * %r20 contains the system call number, %r2 contains whence w...

...e, and that pathnames should be +# accordingly. +# + +# Special CFLAGS for the divide code +DIVCFLAGS = $(KLIBCREQFLAGS) $(KLIBCARCHREQFLAGS) \ + -O3 -fomit-frame-pointer -fcall-saved-1 -fcall-saved-2 \ + -fcall-saved-3 -fcall-saved-4 -fcall-saved-5 -fcall-saved-6 \ + -fcall-saved-7 -fcall-saved-8 -ffixed-15 -fcall-saved-16 \ + -fcall-saved-17 -fcall-saved-18 -fcall-saved-19 -fcall-saved-20 \ + -fcall-saved-21 -fcall-saved-22 -ffixed-23 -fcall-saved-24 \ + -ffixed-25 -ffixed-27 + +KLIBCARCHOBJS := arch/$(KLIBCARCH)/pipe.o arch/$(KLIBCARCH)/setjmp.o +KLIBCARCHOBJS += arch/$(KLIBCARCH)/syscall.o...