similar to: [LLVMdev] endian independence

On Oct 21, 2008, at 2:27 AM, Jay Foad wrote: > Hi, > > I'd like to use LLVM to compile and optimise code when I don't know > whether the target CPU is big- or little-endian. This would allow me > to create a single optimised LLVM bitcode binary of an application, > and then run it through a JIT compiler on systems of differening > endianness. Ok. > I realise that

>> I'm already working on this myself. Would you be interested in having >> this work contributed back to LLVM? > > If this were to better support target independent languages, it would > be very useful. If you're just trying to *reduce* the endianness > assumptions that leak through, I don't think it's a good approach. > There is just no way to solve

On Oct 27, 2008, at 3:14 AM, Jay Foad wrote: >>> I'm already working on this myself. Would you be interested in >>> having >>> this work contributed back to LLVM? >> >> If this were to better support target independent languages, it would >> be very useful. If you're just trying to *reduce* the endianness >> assumptions that leak

Hi, On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote: > Hello fellow LLVMers and Clangstas, > > We want to make Clang great, and we need your help! > > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've

I can't switch to clang on my project until it can handle boost headers. On Thu, Apr 15, 2010 at 2:17 AM, Rene Rebe <rene at exactcode.de> wrote: > Hi, > > On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote: > >> Hello fellow LLVMers and Clangstas, >> >> We want to make Clang great, and we need your help! >> >> Helping is easy: just build Clang

Hello fellow LLVMers and Clangstas, We want to make Clang great, and we need your help! Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor

Hi All, I've finished the first draft of the 2.8 release notes: http://llvm.org/docs/ReleaseNotes.html Please feel free to commit improvements and enhancements. There are "a lot" of changes that went into 2.8, but I think I've scraped most of them out of the commits. However, it is also highly likely that I missed something, so if I missed your favorite feature, please speak

Hi all, today we had a performance issue transfering a big amount of data where one file was over 50GB. Rsync was tunneled over SSH and we expected the data to be synced within hours. However after over 10 hours the data is still not synced ... The sending box has rsync running with 60-80 % CPU load (2GHz Pentium 4) while the receiver is nearly idle. So far I had no acces to the poblematic

No, this is not the case. Just because you compile something to LLVM IR does not make the thing you compiled work on every architecture. You may even be able to retarget it to any architecture (it depends), but this in no way means the result will *actually work*. The LLVM IR generated by llvm-gcc is very architecture dependent. Theoretically you could make a C compiler that was mostly C

Hi all, Speex currently decides endianness at configure-time. This causes the ppc half of Mac universal binaries to have some endianness problems. Most notably, the header built by speex_packet_to_header() has incorrect byte-ordering. This Apple developer page describes the incantation that can be used to build universal binaries on Mac. It also highlights the configure-time versus compile-time

does that mean .o generated with gcc (.c -> .s and .s -> .o) will not contain llvm ir? i meant, final kernel bitcode ir arch independent and can be JIT with any arch-specific backend. Is it not the case? thanks, ashish On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani > <ashish.bijlani at

I wonder if this could be handle specifying that certain address spaces have one or another endianness, which is not necessarily the same as the processor endianness. Your main requirement seems to be that you need to access to banks of memory, with different endianess, and that you the first stage IR to be able to be run on either endianness processor, without change. I would assume that any

On 24 February 2014 18:32, Daniel Dunbar <daniel at zuster.org> wrote: > $(error "ENDIAN is $ENDIAN"), before and after the include of > Makefile.config and Makefile.singlesrc (which includes Makefile.programs). Hi Daniel, Thanks, that did the trick! ;) In TargetConfig.mk.in: #ifdef __LITTLE_ENDIAN__ ENDIAN := little #else ENDIAN := big #endif Seems like it should be

On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: > On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > virtio/vhost: cross endian support > > Ugh. Does this really have to be dynamic? > > Can't virtio do the sane thing, and just use a _fixed_ endianness? > > Doing a unconditional byte swap is faster and simpler

On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: > On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > virtio/vhost: cross endian support > > Ugh. Does this really have to be dynamic? > > Can't virtio do the sane thing, and just use a _fixed_ endianness? > > Doing a unconditional byte swap is faster and simpler

From: James Molloy [mailto:james.molloy at arm.com] Sent: Tuesday, October 04, 2011 12:06 AM To: Villmow, Micah; llvmdev at cs.uiuc.edu Subject: RE: [RFC] Proposal to make LLVM-IR endian agnostic Hi Micah, I'm no core developer, but FWIW here are my thoughts: I'm general I think the patch is too OpenCL oriented [Villmow, Micah] I agree, but this is mainly to solve a problem that is

On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: >> >> Hi! >> >> Recently I have been investigating some strange migration problems on >> s390x. >> >> It turned out under certain circumstances vhost_net corrupts avail.idx by >> using wrong endianness. [..] >>

On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: >> >> Hi! >> >> Recently I have been investigating some strange migration problems on >> s390x. >> >> It turned out under certain circumstances vhost_net corrupts avail.idx by >> using wrong endianness. [..] >>

On Fri, Jan 27, 2017 at 02:37:47PM +0100, Greg Kurz wrote: > On Fri, 27 Jan 2017 13:24:13 +0100 > Halil Pasic <pasic at linux.vnet.ibm.com> wrote: > > > On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > > > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: > > >> > > >> Hi! > > >> > > >> Recently I have

On Fri, Jan 27, 2017 at 02:37:47PM +0100, Greg Kurz wrote: > On Fri, 27 Jan 2017 13:24:13 +0100 > Halil Pasic <pasic at linux.vnet.ibm.com> wrote: > > > On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > > > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: > > >> > > >> Hi! > > >> > > >> Recently I have