similar to: [LLVMdev] questions about ARM EABI attributes

Yes, I see the load is 8-byte aligned in the bit code. My question was, assuming that arguments requiring double word alignment have to be passed in even/odd registers, how does the backend know that %0 has to be passed in register r2 and r3? *tail call arm_aapcscc void (i32, ...)* @foo0(i32 1, [2 x i32] %0) nounwindt * It doesn't seem that ARM backend can figure out that "[2 x i32]

See ARMCallingConv.td:113. The alignment of the arg is checked and if it's 8-byte aligned, the proper registers are chosen. deep On Tue, Aug 7, 2012 at 1:20 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Yes, I see the load is 8-byte aligned in the bit code. > > My question was, assuming that arguments requiring double word alignment > have to be passed in even/odd

When I compile this program *$ cat vararg1-main.c typedef struct { double d; } S0; S0 g1; void foo0(int a, ...); int main(int argc, char **argv) { S0 s0 = { 2.0 }; foo0(1, s0); printf("%f\n", g1.d); * * return 0; }* with this command, *$ clang -target arm-none-linux-gnueabi-gcc -ccc-clang-archs armv7 -emit-llvm vararg1-main.c -S -o vararg1-main.ll -O3* I get this

On Aug 6, 2012, at 3:21 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > When I compile this program > > $ cat vararg1-main.c > > typedef struct { > double d; > } S0; > > S0 g1; > > void foo0(int a, ...); > > int main(int argc, char **argv) { > S0 s0 = { 2.0 }; > > foo0(1, s0); > > printf("%f\n", g1.d); >

To continue the discussion I started last year (see the link below) on embedding command-line options in bitcode, I came up with a plan to improve the way the backend changes UnsafeFPMath on a per-function basis. The code in trunk currently resets TargetOptions::UnsafeFPMath at the beginning of SelectionDAGISel::runOnMachineFunction to enable compiling one function with “unsafe-fp-math=true” and

I'm trying to find a way to emulate a floating point instruction, say a floating point add. My understanding is that in order to do that I need to execute setOperationAction(ISD::FADD, (MVT::f32, Expand); setOperationAction(ISD::FADD, (MVT::f64, Expand); in MyTargetISelLowering.cpp, MyTargetLowering::MyTargetLowering(...). However for some reason I'm still seeing a floating point add in

Dear all, I don't get how llvm handles functions with __attribute__((noreturn)). It seems that LR register is backed up on the stack whilst it will never be used to return from a 'noreturn' function. I have this problem with a home-made backend but it seems that ARM flavour of clang has same behaviour. By the way, SP is also saved, I don't understand why. Is there a syntax error

On Aug 6, 2012, at 6:58 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > See ARMCallingConv.td:113. The alignment of the arg is checked and if > it's 8-byte aligned, the proper registers are chosen. Are you sure? In this case, it looks like the frontend is translating the argument type to [2 x i32], so it's not going to have 8-byte alignment. This looks like a bug to

Hi Divacky, I have an armv7 variant that supports hardware division (extension). For my variant, I use ".cpu cortex-a9" and division attribute(.eabi_attribute 44, 2 @ Tag_DIV_use) to let the assembler do the right thing if it encounters a division instruction. With your path, the .cpu directive is used to fetch the available features of a CPU and ignores the eabi attributes. What

On Sun, Jul 22, 2012 at 11:12 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 22 July 2012 22:03, salvatore benedetto > <salvatore.benedetto at gmail.com> wrote: >> While we are at it, if a new comer would like to understand where everything >> takes place, where should he look? >> >> I did a grep in the source and eventually ended up in

Hi, although I've done S3 dispatching for more than a decade now, I think I managed to overlook/avoid the following pitfall when using NextMethod(): If you explicitly pass argument '...' to NextMethod(), you will effectively pass those argument twice to the "next" method! EXAMPLE: foo0 <- function(...) UseMethod("foo0"); foo1 <- function(...)

Hi the list I have package foo0 with a big dataset 'myData'. In DESCRIPTION, if I use 'LazyData: no', then I get: - when I open a R session : memory used=20 908 - when I attach 'library(foo0)' : memory used=24364 - then I load the set 'data(myData)' : memory used=39 668 If I use LazyData: yes', then I get - when I open a R session : memory used=20 908

On Fri, Feb 25, 2011 at 12:16 PM, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > On Thursday 03 February 2011 14:14:28 Renato Golin wrote: >> On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> > wrote: >> > I have submitted a bug some time ago to LLVM bugtracker: >> > http://llvm.org/bugs/show_bug.cgi?id=8931 >>

On Thursday 03 February 2011 14:14:28 Renato Golin wrote: > On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > > I have submitted a bug some time ago to LLVM bugtracker: > > http://llvm.org/bugs/show_bug.cgi?id=8931 > > Hi Siarhei, > > This is a really silly bug with a simple fix. > > We have a similar patch here

Hi the list In the DESCRIPTION file of my package foo0, I have: Depends: foo1 Imports: foo2 Suggest: foo3 Enhence: foo4 If I understand correctly, to install foo0 on my computer, I need to already have foo1, foo2, foo3. foo4 is not necessary. I my R sesssion, when I will write: library(foo0), then the package foo1 will be attach. foo2, foo3 and foo4 will not. Is that correct? But what is

Dear R developers, Taking advantage of the yesterday discussion about the use of Depends/Import/Suggests/Enhances, I would like to add a related question. Let's assume, in the DESCRIPTION file of my package foo0, I have: Depends: foo1 Imports: foo2 while in the NAMESPACE file of my package I have importFrom("foo2", f2) and within my package I use the following two external

On Wed, Jul 18, 2012 at 6:08 PM, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > On Wed, Jul 18, 2012 at 5:45 PM, Renato Golin <rengolin at systemcall.org> wrote: >> On 18 July 2012 15:46, salvatore benedetto >> <salvatore.benedetto at gmail.com> wrote: >>> $ clang++ -ccc-host-triple thumbv7m-none-gnueabi noInclude.cpp -c >>>

Hi, I wanted to know if it was possible to force ARM backend to compile a function in ARM while the rest is in Thumb mode. I tried the attributes which is used in GCC but it doesn't work. Here is what I tried: https://pastebin.com/jCr5LPUY Thanks in advance, Uvekilledkenny -------------- next part -------------- An HTML attachment was scrubbed... URL:

Umesh, Makes some sort of sense to me, OTOH: If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH encoding T1 (2 bytes opcode) as opposed to the encoding T2 (which is a 4 bytes opcode). A On Tue, Oct 15, 2013 at 2:59 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com>wrote: > Hi

Hi andrea, R11 treated as frame pointer at arm backend , which is fixed again . Thanks Umesh On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote: > Umesh, > Makes some sort of sense to me, OTOH: > If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH