search for: psabi

...Linux. Yours - Michael -----Original Message----- From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Monday, June 04, 2012 5:09 PM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu Subject: [cfe-commits] [PATCH] add x32 psABI support Hi, Folks There are 2 feature support patches adding X32 psABI support (https://sites.google.com/site/x32abi/), respectively to LLVM and clang. The patch to LLVM adds X32 psABI support and introduce a new 'X32' environment for x86-64 target to tell X32 psABI from LP64 psABI (i.e....

Hi Folks, Anyone got chance to review the patch adding X32 psABI support? Yours - Michael -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Tuesday, June 05, 2012 11:18 AM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu; llvmdev at cs.uiuc.edu; cfe-dev...

Here is the link: https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 -- H.J.

...rd Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu <hjl.tools at gmail.com> wrote: >> Here is the link: >> >> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 > > The document contains this claim (as do many other psABI documents): > > "Bit-fields that are neither signed nor unsigned > always have non-negative values. Although they may have type char, > short, int, or long (which can have negative values), these bit-fields > have the same range as a bit-field of the same size with the > corr...

On Thu, 22 Jan 2015, H.J. Lu wrote: > Here is the link: > > https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 I sent the following reply to the ia32-abi list but haven't yet received it back from the list - you might want to check if it's stuck in moderation somewhere: I would suggest that rather than using old terms such as "single", "double"

Hi Devs, since risc-v has a register $tp which is thread pointer. is it possible to have __builtin_thread_pointer for RISC-V? I am not sure what could be corresponding instructions? ./kamlesh

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

...lvm-dev <llvm-dev at lists.llvm.org> >> Subject: [EXT] Re: [llvm-dev] RISC-V LLVM sync-up call 19 Mar 2020 >> >> Here's the draft proposal for the compact code model on RV. I'd appreciate your feedback before I propose it to the foundation and go about updating the psABI. >> >> Thank you, >> >> __ >> Evandro Menezes ◊ SiFive ◊ Austin, TX >> >> >> >> On Mar 19, 2020, at 8:58, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> For background on these calls, see >> &...

...gt; > > * glibc and the compilers should align in their definition of the > > levels, so that developers can use an -march= option to build for a > > particular level that is recognized by glibc. This is why I think the > > description of the levels should go into the psABI supplement. > > > > * A preference order for these levels avoids falling back to the K8 > > baseline if the platform progresses to a new version due to > > glibc/kernel/hypervisor/hardware upgrades. > > > > I'm including a proposal for the levels below....

Hi, I've tracked down what I believe is a bug in lld's relocation processing for R_X86_64_PC32 REL relocations. I'm producing the object file in a slightly unusual way: I'm using objcopy on a relocatable i386 ELF object file to convert it to x86_64 which transforms a R_386_PC32 into a R_X86_64_PC32. Steps to reproduce: 1. Assemble the attached bug.asm using nasm and note the

...abi/wiki/linux-abi-draft.pdf [2] - "CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" (https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf) [3] - "System V Application Binary Interface" ch.13 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf) Best regards, George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/b2687b84/attachment.html>

...these are the things you should build”. * glibc and the compilers should align in their definition of the levels, so that developers can use an -march= option to build for a particular level that is recognized by glibc. This is why I think the description of the levels should go into the psABI supplement. * A preference order for these levels avoids falling back to the K8 baseline if the platform progresses to a new version due to glibc/kernel/hypervisor/hardware upgrades. I'm including a proposal for the levels below. I use single letters for them, but I expect that the concr...

...* Non-scalable RVV support (Fraser) * Patches we might want to discuss: * Zfh (D90738) * Setrounding/flt_rounds lowering * PrologEpilogInserter floating emergency spill slots (D89239) * Any bitmanip patches people want to discuss? * Other: * Heads up on https://github.com/riscv/riscv-elf-psabi-doc/issues/163 * Any other business? Best, Alex

...tart to create vendor-specific forks in the feature progression, things get complicated. Do you think we need to figure this out in this iteration? If yes, then I really need a semi-formal description of the selection criteria for this x86-zen-avx2 directory, so that I can passed it along with my psABI proposal. Thanks, Florian

...-draft.pdf > > [2] - "CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" (https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf) > > [3] - "System V Application Binary Interface" ch.13 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf) > > Best regards, > George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/335fde8f/attachment.html>

..._vectorcall), and these 3 are passed in XMM0-XMM2, which is closer to the GCC behavior. Unfortunately, it seems like there is no ABI specification to support either behavior as "correct": while the x32 ("ILP32") ABI explicitly specifies XMM0-XMM2, the latest version of the i386 psABI is too old to contain any useful information. Still, XMM0-XMM2 looks like the common choice, and I think the current clang behavior should be considered a bug. The problem is that, regardless of whether it's a bug or not, this behavior has been in place for many years, and changing it would me...

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call each Thursday at 4pm GMT, via <https://meet.google.com/ske-zcog-spp>. I've created a shared calendar which may help

...ould be non-descript, and either be numbers or characters, of which I would vote for characters, i.e. A, B, C. Obviously, as already mentioned here, the mapping of level to feature set needs to be described in documentation somewhere, and should be maintained by either glibc, glibc/gcc/llvm or psABI people. I don't have many suggestions about vendor names, be them ISA-subset market names, or core names or company names. I will just note that using such names has lead to an explosion of number of names without very good separation between them. As long as we're only talking about...

...andle data types whose representation isn't defined by the ABI we're targeting? 3. What should the ABI do with half-precision floats? Working backward... The third question here is obviously target specific. I've talked to HJ Lu about this, and he's working on an update to the x86 psABI. I believe that his eventual proposal will follow the lines of what you (Ahmed) suggested below, but I'm not completely proficient at comprehending ABI definitions so there may be some subtlety that I am misunderstanding in what he told me. I also talked to Craig about would be involved in maki...

...ay <http://lists.llvm.org/pipermail/llvm-dev/2015-March/083554.html> * Previous suggestions that we really want an "onstack" attribute <http://lists.llvm.org/pipermail/llvm-dev/2012-May/049406.html> I'm working with a calling convention (https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md) where structs of up to two words in length should be passed in registers, but otherwise on the stack (EXCEPT in the case where there is only one argument register left, in which case the struct is split between that register and the stack). Is there a consensus now on...