search for: agnostics

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:

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

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:

On 10/03/2011 09:36 PM, Villmow, Micah wrote: > 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. > > > > A second smaller

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

hi guys, I've been going round in circles trying to workout the best way to handle vendor agnostic images and in the interest of sanity and actually getting something out of the door - it looks like the best pln is to get the vendor specific requirements and push images with them ( and suitability marked ) With that in mind, AWS is a good target to start with. Do people have opinions on : -

Years ago Accusys made an IDE raid controller that presented itself as one drive to the BIOS, making the unit completely OS agnostic. Anything like that out there, anymore? Cheers, Brett.

A month ago I mentioned on this list work on a automated package deployment tool for Windows systems, which is server agnostic. At the time, I didn't have the time to put it up in a place for public consumption. I do now. The utility is named wpkg (punny isn't it?) It's nothing more than a simple .js (jscript) file which needs to be run on Windows, from a directory containing three

On Thu, Oct 29, 2015 at 2:08 PM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Oct 29, 2015, at 10:11 AM, Dave Bartolomeo via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Proposed Design > > How Debug Info is Generated > > The CodeView type records for a compilation unit will be generated by > the front-end

I have a rails 3.rc app that I''m developing. I have a text entry in one my models that can sometimes be quite big. I tried setting :limit => 4294967296 on the text column in my migration file but this doesn''t seem to have any effect. The column is till created as a TEXT column rather than MEDIUMTEXT or LONGTEXT. Does anyone have any idea why this might be happening? Is there

Hi Edwin, > FWIW here is another way to do it (which is approximately what ClamAV does currently) by introducing just one intrinsic: > declare i1 @llvm.is_bigendian() why is an intrinsic needed? It is easy to write a small LLVM IR function that computes this. For example: define i1 @is_big_endian() { %ip = alloca i16 store i16 1, i16* %ip %cp = bitcast i16* %ip to i8* %c =

From: Sylvain Gault <sylvain.gault at gmail.com> As there is no need for an x86_64 linker script, the i386 one can be put in the core directory directly. This partially revert commit d8eede3f2a360163235fad222a0190cd7c5bef38 which splitted several linker scripts into i386 and x86_64 versions. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- core/Makefile |

Hello folks, I am happy to release version 1.0 of Invoker. Invoker is a utility belt for managing processes in development environment. Use it for managing multiple processes with ease. Use it for developing web applications on different local domains without /etc/hosts hacks. * Installation gem install invoker * Usage Invoker supports formean like process supervision and also makes http

Brief answer, but can go into detail later: If this is the right idea, lets do it for dwarf too & generalize the support to work for both. It's certainly something we've considered, to save all the complexity of representing essentially static data in an intermediate form. That said, given some of the stuff we have for lto, for example (deallocating/merging types etc) I'm not

Definitely having someone who knows both formats well would be an advantage. Dave B might be in the best position to do this, so hopefully he can provide a couple more examples of areas where he has trouble expressing CV information entirely in the backend. Regardless of what everyone ends up deciding on with regards to the front-end / back-discussion, I want to suggest separating the work into

Hello, Samuel Crow wrote: > It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. > Which ones llvm assembler instructions is not endian-agnostic? -- Ivan

On Tue, Jul 20, 2010 at 2:46 PM, Talin <viridia at gmail.com> wrote: > 1) For frontends that generate target-agnostic code, it is difficult to > calculate how large this struct should be. (Which is larger, 3 int32s or two > pointers? You don't know unless your frontend knows the size of a pointer.) > In my case, I finally decided to abandon my goal of making my frontend >

Am 01.06.2011 23:25, schrieb Nate Fries: > That said, it seems like it ought to be possible to do the same thing > by emitting bitcode for all supported platform/arch combinations Wait... is bitcode not platform-agnostic? I thought it is. > and > compressing them in an archive, then decompressing and either > interpreting or JIT-compiling the appropriate bitcode for the >

we're using Samba 3.0.10 on a Mac OS X server (XServe), and are accessing files on the XServe from Windows Server 2003. for the specific situation of creating thumbnails of images, i'm seeing a huge perf difference between accessing the same file via mapped drive vs. UNC path. if we map the Z: drive to \\usseast01\assetstorage (Z:\foo.tif), and create a thumbnail of a 1.5MB TIFF file,

On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this dependence should be satisfied by the target system's unwinder, > whatever that is. If folks want to use this libunwind for their platform, > that's fine... but we should probably continue to use libgcc_s and libgcc_eh > on linux when that's the platform's unwinder.