similar to: [LLVMdev] Make LLVM ARM JIT well-formed

Hi Chenwj, The main problem is that the ARM JIT doesn't currently use the MC architecture. There is work ongoing to convert it to use MC, but that is not moving very fast and any work done in the meantime on the current architecture will be thrown away when MC hits - this makes it less worthwhile to try and get the current ARM JIT in decent shape. If active work starts on the MC conversion

Hello, I asked here for kind of reference GCC version which LLVM development team is using for *native* testing on ARM hardware. (no cross compilation!) last week or so. I've been curious myself how the situation looks and so I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5,

On Sun, Jul 3, 2011 at 11:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM >

On 3 July 2011 21:32, Karel Gardas <karel.gardas at centrum.cz> wrote: > please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > Is there anything other I might do for you to get those regressions fixed? Hi Karel, This is great! I can see there's only a handful of errors. All JIT errors seem to be the same (MC). All O2 errors, too (MIPS). The select.ll

On 06/27/11 12:46 PM, Renato Golin wrote: > On 26 June 2011 10:16, Karel Gardas<karel.gardas at centrum.cz> wrote: >> So I'm curious what's *the* recommended compiler on this platform which >> LLVM development is using? > > Hi Karel, > > I'm not sure what test cases you're talking about, but we use > CodeSourcery's GCC and binutils (latests,

Hi Renato, On 07/ 5/11 12:20 PM, Renato Golin wrote: > On 3 July 2011 21:32, Karel Gardas<karel.gardas at centrum.cz> wrote: >> please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ >> >> Is there anything other I might do for you to get those regressions fixed? > > Hi Karel, > > This is great! > > I can see there's only a handful

Hi, Eli > Mmm... and I just realized I really can't help track this down because > the code paths in question are probably Linux-specific. I spent a I add the following line back to lib/Support/Unix/Host.inc, Arch = "arm"; And examples/HowToUseJIT works fine. Regards, chenwj [1] http://llvm.org/viewvc/llvm-project?view=rev&revision=131463 -- Wei-Ren Chen (陳韋任)

On Sun, Jul 3, 2011 at 1:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM >

How can I find out, in llvm-c API, whether a basic block is well formed? In C++ I could call getTerminator and test for NULL. -- Seo Sanghyeon

Hi all, Is there an easy way to check that debug metadata in a .ll file are well formed ? Thanks for you answers Seb

On 2008-12-19, at 09:18, Seo Sanghyeon wrote: > How can I find out, in llvm-c API, whether a basic block is well > formed? In C++ I could call getTerminator and test for NULL. There's not currently a binding for this. In general, there's incomplete support for inspection and analysis through the C bindings. BasicBlock::getTerminator() is just a convenient way to spell for

Hi Seb, On 05/07/13 11:08, Sebastien DELDON-GNB wrote: > Hi all, > > Is there an easy way to check that debug metadata in a .ll file are well formed ? > > Thanks for you answers I don't think so. It would be great if the verifier checked debug and other standard meta data. Ciao, Duncan.

This is the only driver which doesn't hand virtqueue_add_inbuf and virtqueue_add_outbuf a well-formed, well-terminated sg. Fix it, so we can make virtio_add_* simpler. pktgen results: modprobe pktgen echo 'add_device eth0' > /proc/net/pktgen/kpktgend_0 echo nowait 1 > /proc/net/pktgen/eth0 echo count 1000000 > /proc/net/pktgen/eth0 echo clone_skb 100000 >

On 07/ 8/11 05:26 PM, Eli Friedman wrote: > Given that revision range, the only remotely likely culprit is 131463. > Which basically means that it "broke" because the default target > features changed. And you are right here. 131463 == 131464 which is buggy. 131462 is OK. Thanks, Karel

On Fri, Sep 05, 2014 at 12:40:50PM +0200, Paolo Bonzini wrote: > Il 03/09/2014 06:29, Rusty Russell ha scritto: > > + sg_init_table(rq->sg, MAX_SKB_FRAGS + 2); > > I think 2 is enough here. That said... > > > sg_set_buf(rq->sg, &hdr->hdr, sizeof hdr->hdr); > > - > > skb_to_sgvec(skb, rq->sg + 1, 0, skb->len); > > > >

2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > if you transformed > > lifetime.start(%p) > use %p > lifetime.end(%p) > into > > if (c) > lifetime.start(%p) > use %p > lifetime.end(%p) > > That is *definitely* a bug in polly. > Stack coloring should be able to handle it if that is the original IR but that is definitely not a

2017-03-31 0:19 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: >> I modified Polly's code generator to produce >> >> if (c) { >> llvm.lifetime.start(&var) >> } else { >> llvm.lifetime.start(&var) >> } >> [...] >> llvm.lifetime.end(&var) >> >> and it does not miscompile

2017-03-31 0:54 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > I'm curious, btw, what made it think the above is legal. > The intrinsics are marked as touching memory, having side effects, etc. The precedes my involvement with Polly. Polly has a list of intrinsics that can be safely ignored, e.g. llvm.dbg.value/llvm.gbg.declare. The lifetime markers are also in this list.

Does String.evalScripts() work when the opening SCRIPT tag of a SCRIPT block contains common attributes? I''ve tried and it does not appear to be working. Here''s an example: <script type="text/javascript" charset="ISO-8859-1" language="JavaScript"> //<![CDATA[ <!-- alert(''look! it works!''); //--> //]]>

Hello, I'm trying to find myself, but anyway, I'm curious what's the recommended GNU C++ version for LLVM compilation on ARM/Linux platform? I'm using various version of Ubuntu and so far the best compiler I found was 4.4.1 (Ubuntu 4.4.1-4ubuntu9)[1]. With this and with just -O1 as optimize option I've been able to get to 1 failing testcase. Other tested were 4.4.3 and