search for: evzen

...between this patch and the one I had been sitting on are: * We have opposite condition codes in our FP comparisons. * This patch has integer division, which seems like a good thing, but wasn't needed for my A9 target. Are you sure about the comparisons? deep On Tue, Sep 28, 2010 at 9:11 AM, Evzen Muller <evzen.muller at arm.com> wrote: > Hi Deep, > > Loop for setting all libcall calling conventions to ARM_AAPCS was > in original version, but I agree that it could have unexpected > side effects. > Attached patch sets calling convention only for added libcalls. > &g...

On Mon, Sep 27, 2010 at 5:02 PM, Evzen Muller <evzen.muller at arm.com> wrote: > > To make it easier to review & commit I have split and cleaned-up our > original > "Support for ARM Run-Time ABI" patch, this part adds support for calls which > > can be mapped using setLibcallName. As noted in the e...

> * We have opposite condition codes in our FP comparisons. No, Evzen is correct. The condcode is used to test the libcall result against zero and EABI libcalls return 1 in case of "true" result of the comparison, thus we have to invert the condcode agains the default value. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Sa...

Hi, To make it easier to review & commit I have split and cleaned-up our original "Support for ARM Run-Time ABI" patch, this part adds support for calls which can be mapped using setLibcallName. Thanks Evzen -------------- next part -------------- A non-text attachment was scrubbed... Name: arm-rtabi.patch Type: application/octet-stream Size: 6090 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100927/5b5a038b/attachment.obj>

On Tue, Sep 28, 2010 at 9:24 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> * We have opposite condition codes in our FP comparisons. > No, Evzen is correct. The condcode is used to test the libcall result > against zero and EABI libcalls return 1 in case of "true" result of > the comparison, > thus we have to invert the condcode agains the default value. I guess I never saw a float cmp libcall in my testing, which makes...

Hi Anton, could you please look at the second part of RTABI patch (support for REM/UREM) I sent yesterday? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100927/108762.html Thanks Evzen >> I guess I never saw a float cmp libcall in my testing, which makes >> sense for the platforms I was testing on. >> >> LGTM then. >I will apply the patch

Here's a concrete example of what I'm having problems with: trying to use LowerOperation to replace one node with two nodes. Imagine I have a new instruction "read_world" that sets the status flags according to some kind of global state. In order to generate this instruction I have a built-in function with the prototype "int __builtin_read_world(void)". I also have a

On 01/18/2011 06:38 PM, Bin Zeng wrote: > Hi folks, > > I have been stumped on a compilation problem when I tried to build > 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. > First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since > the default C standard of Clang is c99 while that of gcc is c89. It > reported this error: >

Hi folks, I have been stumped on a compilation problem when I tried to build 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since the default C standard of Clang is c99 while that of gcc is c89. It reported this error: ./c-gperf.h:14:1: error: unknown type name 'inline' inline ^