similar to: fixup_aarch64_movw support for COFF AArch64

Martin, Thanks for your suggestion. I look at these tests, try to make them work for COFF. Adam On 2019. 10. 02. 12:23, Martin Storsjö wrote: > On Wed, 2 Oct 2019, Adam Kallai wrote: > >> I'm working Chromium targeting Windows on ARM64 platform. As a part >> of this work I ran into an issue related to llvm in Swiftshader. >> >> Currently fixup_aarch64_movw

Dear list, this is not a problem report -- I would like to ask for advise what the recommended and safe way to perform the following is or what problems might arise in doing it differently. The question is: What is the recommended way of providing a default value in a prototype statement for a derived class for a slot provided from a parent class? I have first consulted the methods package

Hi all, I thought some of you might be interested to know that TransGaming SwiftShader now features a back-end based on LLVM. SwiftShader is a high-performance 3D software rendering toolkit (http://transgaming.com/business/swiftshader/technology/). It has recently been licensed by Adobe for the Flash Molehill 3D API (http://labs.adobe.com/technologies/flash/molehill/). That version

Hi Nicolas, > I thought some of you might be interested to know that TransGaming SwiftShader > now features a back-end based on LLVM. SwiftShader is a high-performance 3D > software rendering toolkit it sounds very nice - pity it's only for Windows! Ciao, Duncan.

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Hello all, For the past couple of months I've been writing a new llvm backend for Renesas RL78 MCU: https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rl78.html The software manual which contains all there is to know about RL78 is available here: https://www.renesas.com/us/en/doc/products/mpumcu/doc/rl78/r01us0015ej0220_rl78.pdf The motivation behind this is the

Hi everyone. In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup() there is a curious call to getFixupKindNumBytes() - which can return 1,2, 3, or 4 depending upon the FixupKind The code in ApplyFixup() seems to be lifted from the X86. AFAIK, the initial Fixup.Offset() is always divisible by 4, at least for ARM mode - i.e. it is always at the instruction boundary. it looks like

Hi David, Thank for very much for your reply! I got a reply on the clang mailing list in April from Dmitri: http://lists.llvm.org/pipermail/cfe-dev/2020-April/065115.html and following his advice “attaching pragmas as attributes to functions” I managed to do it, it was actually quite easy. >>Compatibility with an existing compiler is usually compelling - are the compilers you're

I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding

Jim, Both the branch and the branch target are in the same function. This is known delta and should not matter where it is relocated because the delta will remain the same once it is a .o or later. I just want to know how to tell the compiler that this expression is target offset - branch offset. More generally, I want to know the rules for setting up expressions in general. I have no idea if

hi, does anyone know how to resolve this? It's a very simple IR file (below), fails with: LLVM ERROR: invalid symbol kind for ADRP relocation PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: \p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe -O0 debug_output(1).ll -filetype=obj #0 0x01522349

Daniel: Thanks for your detailed response. I had seen the discussion from earlier this year, but when I read it, I didn't expect it would be so difficult to get just one bit of information where I wanted it. :-) Thanks for the heads up about clang not necessarily setting ABIname. I have at least enough of that working already that I can generate the appropriate assembly source. After doing a

Hi guys, I got a really weird questions in my mind... You probably know, Transgaming Swiftshader is converting on the fly DirectX9 GPU accesses to CPU (aka 100% software rendering). (With this, wrapped inside Wine, I can start some games that never worked before). But, software rendering is too slow to play games seriously. Maybe it's a fool idea, but could Wine share back computation to

Hal, that’s a good point. There are more manually-maintained tables in the X86 backend that should probably be tablegened: the memory-folding tables and ReplaceableInstrs, to name a couple. If you have ideas on how to get these auto-generated, please let us know. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Wednesday, November 23, 2016

On 5 May 2016 at 13:01, Bradley Smith <Bradley.Smith at arm.com> wrote: > Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used > for specifying an architecture version to target whereas aarch64/arm64 don’t > convey any information to that effect, does it mean armv8a, armv8.1-a, etc? Hi Bradley, That's a good point. But also, what does "armv8a"

Hi, Right. I'm aware of that. But to Clang, "armv8-a" as an architecture is ARMv8/AArch32. Unless Clang has recently got a lot cleverer than it has been in the past. James On Thu Dec 18 2014 at 9:06:04 AM Christophe Lyon <christophe.lyon at linaro.org> wrote: > On 18 December 2014 at 09:07, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Renato,

Hi David, >>Ah, so this is a commercially backed project? Initially it wasn’t. I started to do this in my own free time and after I got something which I could demonstrate I can be much better than what we currently have with GCC it became part of my day to day job. >>But relatively small? (are you the only engineer working on this?) Yes I’m the only one working on this.

Hi Junmo, I notice that you recently added the __ARM_FEATURE_DOTPROD pre-defined macro for AArch64. Do you plan on also doing the AArch32 part of this? If not, I'm currently working on adding the corresponding intrinsics to LLVM and clang, so I'll add the macro as part of that. Oliver

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. >

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180424/9d3e655d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180424/9d3e655d/attachment-0001.gif>