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 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,

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 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 >

Hello, it looks like I do have infinite loop in llc on linux/armv7 platform somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 seconds delay are: 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd (this=0x7ee90b38, P=0x5c06988) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 103 void setEnd(T *P) { this->EndX = P; }

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

On Fri, Jun 24, 2011 at 9:12 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > it looks like I do have infinite loop in llc on linux/armv7 platform > somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 > seconds delay are: > > 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd > (this=0x7ee90b38, P=0x5c06988)

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

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

On Sat, Sep 12, 2015 at 01:35:48AM +0200, Karel Hendrych wrote: > Comparing simple dd bs=1M count=10000 on dom0 vs domU. Qemu driver > is achieving pretty much the same like dom0. > So you're measuring buffered speed. Try measuring non-buffered (iflag=direct or oflag=direct, depending if you're reading or writing). -- Pasi > Thanks > -- > Karel > > On 7.9.2015

On Mon, Sep 07, 2015 at 05:47:39PM +0200, Karel Hendrych wrote: > ... > > changing from: <driver name='file'/> to: <driver name='tap2'/> makes > the domain start without QEMU. > > However I see much better performance with QEMU (close to dom0, > tested using simple dd writes) than with tap2 driver. Is that > expected? > How did you measure

Hi Jim and Eric! thanks a lot for your fantastically fast reply. I'm going to update and will report tomorrow when all the building is done. Thanks! Karel On 08/29/11 11:36 PM, Jim Grosbach wrote: > Hi Karel, > > Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. > > -Jim > > On Aug 29, 2011, at 2:33

I could delete all records of this server that no longer exists no problem even record type NS I only have these two that there has been no way to erase any other ideas thanks samba-tool dns delete zdtoe-02.dtoe.etecsa.cu dtoe.etecsa.cu _msdcs\010CNF:946b89d3-b07b-4f43-a6b9-0de3bf3f3a10.dtoe.etecsa.cu. NS zdtoe-01.dtoe.etecsa.cu -U administrator GENSEC backend 'gssapi_spnego'

Is possible YP listing in http://dir.xiph.org/cgi-bin/yp-cgi and http://www.oddsock.org/cgi-bin/yp-cgi from Icecast2.2 with source Ices2? Thank you -- P?eji spokojen? den ***************************************************** I'm not really a human, but I play one on earth. *************************************** Karel Du?ek email: mailto://karel.dusek@duhovy.net ICQ#: 1 498 454 721

Hi Karel, Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. -Jim On Aug 29, 2011, at 2:33 PM, Karel Gardas wrote: > Hello, > > I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in

On 06/24/11 06:53 PM, Eli Friedman wrote: > On Fri, Jun 24, 2011 at 9:12 AM, Karel Gardas<karel.gardas at centrum.cz> wrote: >> My question is if it is a known bug or unknown in which case where to >> report it and if also include compiled *.bc file or not. > > Haven't seen it before... see > http://llvm.org/docs/HowToSubmitABug.html , and please do include the

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, not stable, because of new core support) and it works a treat. You can

I don't know if GuaranteedTailCallOpt is in anyone's plans. It might be a good idea to implement some time. I am not sure what GHC's exact needs are, though. Cameron On Jun 17, 2011, at 1:49 PM, Karel Gardas wrote: > > Hello Cameron, > > thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of