similar to: Starcraft running sluggishly?

On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: > As an update to this: > http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 > > Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's

Hi, I have created a workaround to deal with the PIC function call. With this patch, the FastISel will switch back to DAG lowering mechanism if (1) there is a function call in the basic block and (2) the relocation model is PIC. Please have a look. Hoping the patch will help. Sincerely, Logan On Wed, Aug 21, 2013 at 10:17 AM, Gordon Keiser <gkeiser at arxan.com> wrote: > Cool,

lgtm On Wed, Aug 21, 2013 at 3:18 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > LGTM > > On Wed, Aug 21, 2013 at 1:51 PM, Logan Chien <tzuhsiang.chien at gmail.com> > wrote: > > Hi, > > > > I have created a workaround to deal with the PIC function call. With > this > > patch, the FastISel will switch back to DAG lowering

As an update to this: http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's nice to know. The workaround involves marking a single function with attribute((noinline)) and is

LGTM On Wed, Aug 21, 2013 at 1:51 PM, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > Hi, > > I have created a workaround to deal with the PIC function call. With this > patch, the FastISel will switch back to DAG lowering mechanism if (1) there > is a function call in the basic block and (2) the relocation model is PIC. > Please have a look. Hoping the patch will

Cool, I'll file a bug tomorrow at work and add you to the CC list. Thanks! Gordon Keiser Software Development Engineer Arxan Technologies gkeiser at arxan.com www.arxan.com  Protecting the App EconomyT  > -----Original Message----- > From: Eric Christopher [mailto:echristo at gmail.com] > Sent: Tuesday, August 20, 2013 9:47 PM > To: Gordon Keiser > Cc: llvmdev at

That change seems to fix things here. Thanks! -Gordon From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of JF Bastien Sent: Wednesday, August 21, 2013 12:53 PM To: Logan Chien Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Broken PLT on ARM from R183966 I'm not very familiar with relocations but your fix looks the same as

I'm not very familiar with relocations but your fix looks the same as ARMTargetLowering::LowerCall, so from that perspective it lgtm (but I may be missing something). On Wed, Aug 21, 2013 at 8:04 AM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > Hi Anton and JF, > > Thanks for your review. After reading the source code more carefully, I > have come up with a

Hi Gordon, Clang can do it if you include <stdbool.h> .  I found this out when writing a LibC wrapper library for LLVM Bitcode. --Sam >________________________________ >From: Gordon Keiser <gkeiser at arxan.com> >To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> >Sent: Wednesday, September 21, 2011 9:55 PM >Subject: [LLVMdev] Returning i1 type

Hi Anton and JF, Thanks for your review. After reading the source code more carefully, I have come up with a different way fix this issue. We can simply resolve this issue by adding ARMII::MO_PLT flags with MachineInstrBuilder in FastISel pass (without failing back to DAG lowering). The new patch is attached, and the test case is not changed. Sorry for your inconvenience. Please have a

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft

Hi all, I am currently attempting to play Red Alert 2 on my Ubuntu 11.10 installation under Wine. Now, Red Alert 2 will launch fine, as expected on a Windows machine. The most minor error is the campaign selection screen where it takes an "alt-tab" to respond. I'm not so worried about this error. However, when I enter a single player game (Skirmish or Campaign), whenever the game

Hi all. Since I installed SC2 on my Ubuntu 10.04 x86-64 (Phenom II X4 965 BE, 8 GB Ram, nVidia 470 GTX - Driver 260.19.06, USB mic+headphones), I never managed to play at it with Ultra details with more than 12~15 FPS. You could say that the fault is in a slow CPU, bad videocard or lousy sound card (the above USB stuff). But the CPU isn't that bad, the ram quantity is more than enough and

Hi Gordon, You're talking about Thumb mode code here, right? As I understand it, the ARM mode MOV instruction is valid for everything ARMv4 and up. (nit picky side note: CPY is an obsolete mnemonic as of the introduction of unified syntax) Assuming so, using a high register causes headaches, as R8+ are call preserved registers, and the Thumb push/pop instructions can't reference them.

Hi, I was wondering if there was any way to return an i1 type (or something that llvm would accept as one, internally) from a C function compiled with llvm-gcc. My thought from searching around was that it might take rewriting (or at least writing a wrapper to %trunc the result) in assembly. I'm fairly new to LLVM so I may have missed something important. Any thoughts ? Thanks much,

If you install Windows Media Player, will the cutscenes in Fable work?

Filing a bug would be a good start, go ahead and cc me and jfb at google.com. Thanks! -eric On Tue, Aug 20, 2013 at 6:10 PM, Gordon Keiser <gkeiser at arxan.com> wrote: > For ARM targets on linux, revision 183966 made Fast ISel default. > Unfortunately, Fast ISel is broken in terms of applying the ARMII::MO_PLT > flags to calls in PIC mode (at least when emitting assembly); it

Gordon Keiser <gkeiser at arxan.com> writes: > There is (was?) a CMake variable for this if you're going that route. > Setting LLVM_REQUIRES_RTTI=1 enabled an RTTI build that I haven't had > issues with. I don't know what the ./configure equivalent is, sorry. LLVM_REQUIRES_RTTI is an internal variable. It works as you say, but there is no guarantee about it. Adding a

But read the code and then answer the question. :) On 07/25/2012 06:19 PM, Gordon Keiser wrote: > From the comment at the top of the file: > > /* > * This file is used to the C calling conventions with signless > * LLVM. Integer arguments in this convention are promoted to at > * least a 32-bit size. Consequently signed values must be > * sign extended and unsigned

On 04/12/2012 06:29, Michael Spencer wrote: > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: >> As an update to this: >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 >> >> Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release.