similar to: [LLVMdev] Endianness

On 4/05/2015 11:06 PM, Teemu Huovila wrote: > On 05/03/2015 01:48 PM, Reuben Farrelly wrote: >> Hi all, >> >> I've had an interesting use case come up which - to cut the story short - one way to solve the problem I am looking at may be to >> replicate a small number of mailboxes to a third remote server. >> >> I've currently had replication running

With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") --- .../gpu/drm/nouveau/nvkm/engine/device/base.c | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c

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

Hi, As a first step to port the LLVM chain on an in-house big-endian processor, I'm integrating the native assembler as a new '-assemble -arch=' in llvm-mc. All work quite well, I have a correct output ELF format except that generated code is little-endian. I've understood that the endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc

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

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the

One of the projects I am working on with others is to make LLVM-IR endian agnostic. So, I am sending out this proposal for feedback to the LLVM community. I've attached pretty version of the proposal in PDF format and pasted a 80-column safe text version below. I'm looking forward to comments and feedback. Thanks, Micah Villmow Text of Proposal:

Hi Micah, I'm no core developer, but FWIW here are my thoughts: I'm general I think the patch is too OpenCL oriented, and I have some niggling qualms about other parts. Specifically (comments inline): From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: 03 October 2011 19:37 To: llvmdev at cs.uiuc.edu Subject:

> hton and ntoh intrinsics. These are needed to allow target code to > deal with endianness in a target independent way. (Ok, you could > potentially write code that detected endiannes at runtime and chose > multiversioned code based on that, but that is ugly and optimization > prohibiting). > Why not add types with explicit endianess? A trick I use for reading binary files

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

On 04 May 2015, at 17:11, Reuben Farrelly <reuben-dovecot at reub.net> wrote: > > On 4/05/2015 11:06 PM, Teemu Huovila wrote: >> On 05/03/2015 01:48 PM, Reuben Farrelly wrote: >>> Hi all, >>> >>> I've had an interesting use case come up which - to cut the story short - one way to solve the problem I am looking at may be to >>> replicate a

Jim, I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm. Did I miss something? Jack ________________________________________ From: Jim Grosbach [grosbach at apple.com] Sent:

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk wrote: > Why not add types with explicit endianess?... The issues with architecture dependency are far broader than byte order. LLVM in its current form is simply not intended to be machine neutral. Quite the contrary: it is heavily machine dependent!

Hi Jack, I would have expected the Mips backend to be using these routines (or more likely something on top of them) to emit the contents of the data and text sections and thus have the bit-twiddling done by these routines. I take it that's not happening? Basically, this should already work without any additional infrastructure. If it's not, something is broken and bypassing the

On 05/03/2015 01:48 PM, Reuben Farrelly wrote: > Hi all, > > I've had an interesting use case come up which - to cut the story short - one way to solve the problem I am looking at may be to > replicate a small number of mailboxes to a third remote server. > > I've currently had replication running between my main dovecot machine and another remote VM for some time and

Hi all, I've had an interesting use case come up which - to cut the story short - one way to solve the problem I am looking at may be to replicate a small number of mailboxes to a third remote server. I've currently had replication running between my main dovecot machine and another remote VM for some time and working well (so I'm not new to replication and I've got a good

On 5/2/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Well, I don't quite understand why AC_C_BIGENDIAN and the solution > you're proposing is likely to break other big endian machines (the ones > that don't have __BIG_ENDIAN__). Can you send a patch that addresses > that (i.e. still uses AC_C_BIGENDIAN when it works)? It is not that AC_C_BIGENDIAN

On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote: > hi, > > i've got some more things to note. first, the issue is not related to > x86_64 being the host machine - it also happens on i686/linux. > > next, i think (one of) the problem(s) is the use of > [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in > llvm-convert.cpp (see patch below). > >

On Mon, Oct 2, 2023 at 5:20?AM Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > Am 29.09.23 um 21:33 schrieb Kees Cook: > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: > >> This is a batch of patches touching drm for preparing for the coming > >> implementation by GCC and Clang of the __counted_by attribute. Flexible > >> array