similar to: Automatically backing up and restoring x18 around function calls on AArch64?

Hi, I'm sending this discussion to both wine-devel and llvm-dev, to try to keep the discussion open for both sides, to try to find a workable compromise. This was preliminarily discussed on llvm-dev already a few weeks ago. One of the major unresolved issues with Wine for AArch64 is how to handle the platform specific register x18. (https://bugs.winehq.org/show_bug.cgi?id=38780) As

Hi all, This is a RFC on support for Global Register Variables in the Arm backend. Whilst there has been some prior discussion about whether or not LLVM should (or even needs to) support global register variables, today there seems to be a good measure of support for this in both Clang+LLVM (although it is currently limited to SP). When most of this support landed there was some concern

Thank you for your reply Eli, I too was working with Carey on this feature, so please let me reply. On 12/21/18 8:05 PM, Friedman, Eli via llvm-dev wrote: > As a side-note, you might want to check that prologue/epilogue emission won't emit a PUSH/POP that refers to a register reserved this way; we sometimes add an "extra" register to align the stack. Yes, you are right.

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

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In

For the variadic function error with AMD64 abi and windows calling convention on 64bits x86, I find it has been tracked in Bug 20847 (https://llvm.org/bugs/show_bug.cgi?id=20847) (http://reviews.llvm.org/D1622#inline-9345). Do we still plan to fix it? You know, I meet exactly same va_arg mistake with llvm3.7 when I enable the Uefi firmware (http://www.uefi.org/) build with clang. The ms_abi is

Hi Richard, Thank you for the info. I build my code in Ubuntu-64bits with simply commands: “clang X64.c”, then run “./a.out” to see the output. If I replace my va_list, va_start, va_arg va_end with __builtin_ms_va_list, __builtin_ms_va_start, __builtin_ms_va_arg, __builtin_ms_va_end, my code will build fail in Ubuntu with below message. Do you suggest I should build it in windows and not in

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 support. Any opinions? Matthew Curtis. -- Qualcomm Innovation Center,

Hello. I am setting up a smb server running debian etch for a small office. Due to circumstances outside my control, most of the client machines are running Windows Vista Ultimate. The shares are all set up properly, security is set, and we're good to go. Except that the throughput from any of the Vista machines to the server is at best slow and at worst abysmal. After tweaking the

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

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

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

Hi Chris, > From the design perspective, I think it would make sense to represent 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>

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > 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++/

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

> 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

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 -Wall -m64 -O3 -pthread

Hi, I would like to nominate Martin Storsjö as code owner for MinGW changes in LLVM. -Tom

On Oct 3, 2012, at 12:13 AM, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: > Hi Chris, > >> From the design perspective, I think it would make sense to represent 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

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