similar to: [LLVMdev] [global-isel] Type-independence of load/store

On Aug 9, 2013, at 5:12 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Sounds like a really exciting topic; I'd love to be involved in > implementation. We need all the volunteers we can get. ;) >> On the other hand, when types are not used to select register banks, it >> becomes really difficult to explain the difference between load i32 and load >>

> > Other big-endian targets may have similar issues, but I know virtually > > nothing about them. > > ARM's is an interesting implementation of big-endian vectors. AFAIK, other > architectures go all in and use both big-endian lanes and elements. That > makes the problem go away, and you only need one load instruction. The recently published MIPS SIMD Architecture

On Aug 12, 2013, at 7:06 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >>> Other big-endian targets may have similar issues, but I know virtually >>> nothing about them. >> >> ARM's is an interesting implementation of big-endian vectors. AFAIK, other >> architectures go all in and use both big-endian lanes and elements. That >> makes

- Use MAC16_16 macros instead of (sum += a*b) and unroll a loop by 2. It increase performance when using optimized macros (ex: ARMv5E). A possible side effect of loop unroll is that i don't check for odd length here. - Add NEON version of FIR filter and autocorr -- Aur?lien Zanelli Parrot SA 174, quai de Jemmapes 75010 Paris France -------------- next part -------------- diff --git

Hi all, I would like to know if LLVM Neon intrinsics are designed to support only 'Legal' types for NEON units. Using llc -march=arm -mcpu=cortex-a9 vmax4.ll -o vmax4.s on following ll code: ; ModuleID = 'vmax.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32" target triple =

Please ignore my previous mail and patch, there is a new version :). Patch changes are: - Use MAC16_16 macros instead of (sum += a*b) and unroll a loop by 2. It increase performance when using optimized macros (ex: ARMv5E). A possible side effect of loop unroll is that i don't check for odd length here. - Add NEON version of FIR filter and autocorr - Add a section in autoconf in order to

On Fri, Sep 21, 2012 at 1:28 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > I would like to know if LLVM Neon intrinsics are designed to support only 'Legal' types for NEON units. > Using llc -march=arm -mcpu=cortex-a9 vmax4.ll -o vmax4.s on following ll code: > > > ; ModuleID = 'vmax.ll' > target datalayout =

On 21 September 2012 09:28, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following message: > > SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] > > LLVM ERROR: Do not

Hi llvm-dev, I am currently writing a backend for an architecture I am designing in my bachelor's thesis and recently came across the GlobalISel Selection Framework. Should already start using this over the more common Selection DAG? Being new llvm backend development, I am not sure if GlobalISel would be "easier" to implement than ISelDAG and if there is any decent documentation on

Hello Renato, You're pointing me at ARM intrinsics related to loads, problem that I've reported in original e-mail, is not support for vector loads, but support for 'vmaxs'. For instance, there is no vector loads of 16 floats in ARM ISA but it is legal to write in LLVM: ; ModuleID = 'vadd.ll' target datalayout =

Hi, >From http://llvm.org/docs/LangRef.html#bitcast-to-instruction: The 'bitcast' instruction converts value to type ty2. It is always a no-op cast because no bits change with this conversion. The conversion is done as if the value had been stored to memory and read back as type ty2. Pointer (or vector of pointers) types may only be converted to other pointer (or vector of pointers)

Hi Eli, Thanks for the answer, it clarifies the situation for me. Do you know if there is Pass in LLVM that could be adapted to 'legalize' intrinsics calls ? Or shall I define my own intrinsics for non supported types ? Best Regards Seb ________________________________________ De : Eli Friedman [eli.friedman at gmail.com] Date d'envoi : vendredi 21 septembre 2012 11:54 À : Sebastien

> Why can't we represent the loads as select(mask, load(addr), passthru)? This suggests masked-off lanes are free to speculatively load from memory. Whereas proposed semantics is that: > The addressed memory will not be touched for masked-off lanes. In > particular, if all lanes are masked off no address will be accessed. Ayal. -----Original Message----- From: llvmdev-bounces at

----- Original Message ----- > From: "James Molloy" <james at jamesmolloy.co.uk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Quentin Colombet" <qcolombet at apple.com> > Sent: Wednesday, January 13, 2016 9:54:26 AM > Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global

[resending so the message is smaller] ----- Original Message ----- From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> To: "Quentin Colombet" <qcolombet at apple.com> Cc: "llvm-dev" <llvm-dev at lists.llvm.org> Sent: Wednesday, January 13, 2016 2:35:32 AM Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global instruction

> (Right?) Uh no, the register content explicitly does change :( We insert REV instructions (byteswap) on each bitcast. Bitcasts can be merged and elided etc, but conceptually there's a register content change on every bitcast. James On Wed, 13 Jan 2016 at 18:09 Philip Reames <listmail at philipreames.com> wrote: > > > On 01/13/2016 08:01 AM, Hal Finkel via llvm-dev

On Sep 21, 2012, at 2:58 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi Eli, > > Thanks for the answer, it clarifies the situation for me. Do you know if there is Pass in LLVM that could be adapted to 'legalize' intrinsics calls ? > Or shall I define my own intrinsics for non supported types ? You should never generate these sorts of intrinsics with

On Fri, Aug 16, 2013 at 7:51 AM, Daniel Sanders <Daniel.Sanders at imgtec.com>wrote: > Hi,**** > > ** ** > > From http://llvm.org/docs/LangRef.html#bitcast-to-instruction:**** > > ** ** > > The ‘bitcast‘ instruction converts value to type ty2. It is always a no-op > cast because no bits change with this conversion. The conversion is done as > if the value

For anyone looking for a cheap home ZFS server... Dell is having a sale on their PowerEdge SC440 for $199 (regular $598) through 11/12/2008. http://www.dell.com/content/products/productdetails.aspx/pedge_sc440?c=us&cs=04&l=en&s=bsd Its got Dual Core Intel? Pentium?E2180, 2.0GHz, 1MB Cache, 800MHz FSB and you can upgrade the memory (ECC too) to 2gb for 19$ bucks. @$199, I just

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