similar to: [LLVMdev] [PATCH] CPUID for Win64

Hi Chris, I see. While hacking AutoDetectSubtargetFeatures() works for me for now, would it be useful to define an interface for X86Subtarget to change the features in a cleaner way? Would methods like disableSSEn()/enableSSEn() work or do you have another suggestion? I certainly want to avoid a situation where one module uses other settings than another module. Thanks, Nicolas

On Jul 18, 2008, at 8:42 AM, Nicolas Capens wrote: > Hi all, > > How do I properly/conveniently change ISA features of the code to be > generated? For instance I have a Core 2 Duo with SSSE3 but I’d also > like to test whether everything would JIT compile correctly on > something with just SSE2 (a Pentium 4) or even older. In other > words, how do I prevent LLVM from

Henning, I believe the code that is supposed to do this is in: lib/Target/X86/X86Subtarget.cpp in X86Subtarget::AutoDetectSubtargetFeatures() Is there a bug in that function? -Hal On Thu, 24 May 2012 23:56:48 +0200 (CEST) Henning Thielemann <llvm at henning-thielemann.de> wrote: > > On Thu, 24 May 2012, Pan, Wei wrote: > > > Very likely AVX is not enabled in your llc.

I am having problems with my program decoding .ogg files on the Win64 platform and am wondering if this is a known issue or not. I have tried using the prebuilt .dll's, the static .lib's and building from source (1.1.3) and I get the same results. My program is being compiled on a win32 platform, but the decoder fails if I run it on a win64 system. Unfortunately this is being reported

Great! Are there other issues I should be aware of? Félix Le 2010-11-25 à 07:43:23, Anton Korobeynikov a écrit : > Hello Felix > >> I have a project in mind that involves using the JIT for a few targets (x86 >> and x86_64 processors on Mac OS, Linux and Windows). However, there is an >> open bug that says LLVM generates incorrect code for Win64. >> Eli's last

Hello guys, I have a project in mind that involves using the JIT for a few targets (x86 and x86_64 processors on Mac OS, Linux and Windows). However, there is an open bug that says LLVM generates incorrect code for Win64. Eli's last comment on the bug, however, says that it appears to be fixed. I don't have a Win64 box to test it. Can someone confirm that it now works (or still

Hi again, Can anyone tell me about the state of Win64 exceptions? I've noticed that there are a good few related patches since the release of 3.1. Is it working now? Is it likely 3.2 will support Win64 exceptions? Cheers. - Manu -------------- next part -------------- An HTML attachment was scrubbed... URL:

For help: Llvm generated instruction calls a function (extern), the function will have a SEH exception (EXCEPTION_ACCESS_VIOLATION), But JIT can not capture the exception of the EXCEPTION_ACCESS_VIOLATION. I saw Bug 24233. EXCEPTION_ACCESS_VIOLATION exception cannot be captured after modification. How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 ? haifeng.qin at wellintech.com

On Thu, Jul 30, 2009 at 5:32 PM, Peter Shugalev<peter at shugalev.com> wrote: > Hello! > > I've just tried generating Win64 code and the result is not that good. > > First of all, XMM registers are saved without reason to do so. Not only > this slows the performance but leads to random crashes too. XMMs are > stored to the stack with MOVAPS instruction which requires

Hello, I think I've found a bug in the calling convention support for X86-64/ Win64. It doesn't correctly save and restore the XMM registers in the function prolog/epilog. (The problem only exists on Win64, since Linux and Mac OS use calling convention in which these registers are volatile and not callee-saved.) X86RegisterInfo::getCalleeSavedRegs() when called for a Win64

Thanks, Anton! I didn't know about exceptions like _Complex that you mentioned. The only way to support them is to place the burden of correct parameter passing on the front-end, I understand that now. So, today I created a new transformation pass that makes sure that LLVM IR, which works alright with the default Win32 calling conventions, also plays nice with Win64 code within the limited

Felix, > Great! Are there other issues I should be aware of? There might be some issues wrt tailcalls, but I'd not expect anything else to be major broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 30-Jul-09, at 8:54 PM, Eli Friedman wrote: > On Thu, Jul 30, 2009 at 5:32 PM, Peter Shugalev<peter at shugalev.com> > wrote: >> Though the most problematic stuff is the lack of 'shadow zone' >> support >> in Win64 ABI. Or maybe I haven't figured out how to turn this on. In >> Win64 any function can treat 32 bytes of stack (RSP+08h..RSP+28h

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving

Hello Felix > I have a project in mind that involves using the JIT for a few targets (x86 > and x86_64 processors on Mac OS, Linux and Windows). However, there is an > open bug that says LLVM generates incorrect code for Win64. > Eli's last comment on the bug, however, says that it appears to be fixed. > I don't have a Win64 box to test it. Can someone confirm that it now

Nobody? Is this basically dead? Won't happen? In progress? :/ On 12 September 2012 18:53, Manu <turkeyman at gmail.com> wrote: > Hi again, > > Can anyone tell me about the state of Win64 exceptions? > I've noticed that there are a good few related patches since the release > of 3.1. Is it working now? > Is it likely 3.2 will support Win64 exceptions? > >

Hi, Similar questions have come up before on the list and elsewhere but I haven't found a solution yet. winbuilder's install.out shows data.table's .c files compiled with -O3 on Win32 but -O2 on Win64. The same happens on R-Forge. I gather that some packages don't work with -O3 so the default is -O2. I've tried this in data.table's Makevars (entire contents) : ====

Hello > I don't know. I feel reluctant to generate different IRs for Win32 and > for Win64. Unfortunately, you should. Think about differences and between _Complex type and struct {double, double}. >From LLVM's point of view these are same types, however many ABIs have special rules for passing / returning _Complex, this is possible to handle in frontend only. > Since the C

Hi Chandler, Kai contributed the WIN64 SEH patch some time ago on llvm-commits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131118/196105.html it was never completed. Kai also responded in this thread. I opened a phabricator for the patch http://reviews.llvm.org/D3418 Yaron 2014-04-18 12:31 GMT+03:00 Chandler Carruth <chandlerc at google.com>: > > On Tue,

On Jul 20, 2008, at 2:59 AM, Nicolas Capens wrote: > Hi Chris, > > I see. While hacking AutoDetectSubtargetFeatures() works for me for > now, would it be useful to define an interface for X86Subtarget to > change the features in a cleaner way? Would methods like > disableSSEn()/enableSSEn() work or do you have another suggestion? I > certainly want to avoid a