search for: f64s

...be particularly quick on IA64. (No, really!) Register > > allocation is a piece of cake for example, and the IA64 machine model is > > quite simple. > > > > - The IA64 backend is a little odd in that it defines a register class > > for booleans, not just i64s and f64s. > > > > - IA64 users currently suffer from the lack of a solid, > > high-performance, easy-to-use open-source compiler. There are some good > > open-source compilers (ORC, IMPACT) but these break like twigs, and > > aren't really intended for production use....

On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote: > I've just checked in an IA64 backend to LLVM! Woo hoo! And There Was Much Rejoicing in IA64 Land :-). -- Ciao, al ---------------------------------------------------------------------- Al Stone Alter Ego: Linux & Open Source Lab Debian Developer Hewlett-Packard

...great day! Xerxes Sandeep Patel skrev: > After wasting an inordinate amount of time trying to get test-suite to > run on arm-apple-darwin so I could reproduce your results, attached is > a patch that fixes the small copy&paste error of having 8-byte > alignment for stack-allocated f64s instead of the proper 4-byte. I've > updated the patch to the top of trunk changes as well. > > deep >

Hi everyone, I've just checked in an IA64 backend to LLVM! Be warned, it's pretty rough right now. Here are some of the known defects: - No varargs - No alloca - No instruction scheduling/bundling of any sort ...or in other words, it breaks often and when it does work, it's a dog. On the plus side, it _does_ have a tasty new pattern instruction selector. :) Beyond fixing the

After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > I'm not currently setup to be able to run the A/B comparison tests > that test-suite relies upon....

I'm not currently setup to be able to run the A/B comparison tests that test-suite relies upon. Fhourstones-3.1 looks to be the simplest. If you can send me the two .o files from either EABI or Darwin, I can dig into why this went wrong for you. deep On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote: > Sorry I haven't gotten back to you earlier. I have

...2009, at 2:52 AM, Sandeep Patel wrote: > After wasting an inordinate amount of time trying to get test-suite to > run on arm-apple-darwin so I could reproduce your results, attached is > a patch that fixes the small copy&paste error of having 8-byte > alignment for stack-allocated f64s instead of the proper 4-byte. I've > updated the patch to the top of trunk changes as well. Thanks for doing the hard work! Can you document your journey somewhere? :-) Bob, can you review Deep's patch and commit it for him? Thanks, Evan > > deep > > On Fri, Feb 27, 20...

...t; >> After wasting an inordinate amount of time trying to get test-suite >> to >> run on arm-apple-darwin so I could reproduce your results, attached >> is >> a patch that fixes the small copy&paste error of having 8-byte >> alignment for stack-allocated f64s instead of the proper 4-byte. I've >> updated the patch to the top of trunk changes as well. > > Thanks for doing the hard work! Can you document your journey > somewhere? :-) > > Bob, can you review Deep's patch and commit it for him? > > Thanks, > > Evan...

...n x 8 x i1> for the <n x 8 x i32>, and would be split along with it during legalization. As you say, the main legal types for SVE are based around multiples of 128b base types, but for some types we've had to use predication to help. An <n x 2 x f32> can't be extended to use f64s, but when generating code we can create a predicate for 64b element types and use that with 32b float instructions, so that the vector interleaves f32 values with 32bit undefs and gives you an effective <n x 2 x f32> vector. For horizontal pair operations, you would use shuffle instructions...

Hi, Here's the updated RFC for representing scalable vector types and associated constants in IR. I added a section to address questions that came up on the recent patch review. -Graham =================================================== Supporting Scalable Vector Architectures in LLVM IR =================================================== ========== Background ========== *ARMv8-A