similar to: [LLVMdev] Vector cast

On Sat, Jun 21, 2008 at 4:24 PM, Nicolas Capens <nicolas at capens.net> wrote: > I seem to be unable to cast a vector of integers to a vector of floats > (uitofp [4 x i8] to [4 x float], to be exact). It hits an assert in > LegalizeDAG.cpp line 5433: "Unknown int value type". The Assembly Language > Reference Manual's definition of uitofp doesn't indicate that

Hi all, Does PTX backend support llvm sitofp instruction? I failed to compile my llvm source when use llc -march=ptx32. The reason is that the source has a sitofp instruction. After i changed the instruction into uitofp manually, it passed. Thanks in advance, best, Yabin -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Lately we have come to realize how undef makes our life complicated.. Therefore in this email we propose to change the behavior of a few instruction to yield poison instead of undef in error cases. This follows the suggestion of Eli in https://reviews.llvm.org/D33654. Why is undef so bad? - I believe it's not possible to make newgvn correct with undef. See for example the discussion

Since Clang does not seem to allow type casts, such as uchar4 to float4, between vector types, it seems it is necessary to write them as element by element conversions, such as typedef float float4 __attribute__((ext_vector_type(4))); typedef unsigned char uchar4 __attribute__((ext_vector_type(4))); float4 to_float4(uchar4 in) { float4 out = {in.x, in.y, in.z, in.w}; return out; } Running

On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a

Thanks so much for your feedback Simon. I am not sure that what I am proposing here is at odds with what you're referring to (here and in the PR you linked). The key difference AFAICT is that the pattern I am referring to is probably more aptly described as "reducing scalarization" than as "vectorization". The reason I say that is that the inputs are vectors and the output

Hi, I received an internal test case from a game team (it wasn't about this in particular), and I was wondering if there was maybe an opportunity to canonicalize a particular code pattern: %inputi = bitcast <4 x float> %input to <4 x i32> %row0i = and <4 x i32> %inputi, <i32 -1, i32 0, i32 0, i32 0> %row0 = bitcast <4 x i32> %row0i to <4 x float>

Hello, As I understand, in LLVM IR it cannot be determined whether a register of type int is signed or unsigned. If one wants to convert an integer to a double, which instruction should be used:  "uitofp" or "sitofp" ? We track the values taken by all load instructions and we process them using a function. If the value is a pointer, we use int64 as the type of the function

> Does PTX backend support llvm sitofp instruction? Seems it doesn't support sitofp, search "Conversion to f32" in PTXInstrInfo.td. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Hi all, I plan to turn on the new type legalization infrastructure "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision integers such as

Sanjay, I'm looking at some missed optimizations caused by D70246. Here's a test case: define <4 x float> @f(i32 %t32, <4 x float>* %t24) { .entry: %t43 = insertelement <3 x i32> undef, i32 %t32, i32 2 %t44 = bitcast <3 x i32> %t43 to <3 x float> %t45 = shufflevector <3 x float> %t44, <3 x float> undef, <4 x i32> <i32 0, i32 undef,

Hi, Using llvm-stress, I got a crash after Post-RA pseudo expansion, with machine verifier. A 128 bit register %vreg233:subreg_l32<def,read-undef> = LLCRMux %vreg119; GR128Bit:%vreg233 GRX32Bit:%vreg119 gets spilled: %vreg265:subreg_l32<def,read-undef> = LLCRMux %vreg119; GR128Bit:%vreg265 GRX32Bit:%vreg119 ST128 %vreg265, <fi#10>, 0, %noreg;

Hi Stefanus, Thanks for verifying this. Could you patch this or should I open a new bug report and find a generic solution first? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 18:59 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine On 1-Apr-09, at 12:42

Absolutely. We do it for scalars, so it would likely be a matter of just extending it. But that is one example. The issue of extracting elements, performing an operation on each element individually and then rebuilding the vector is likely more prevalent than that. At least I think that is the case, but I'll do some analysis to see if it is so or not. On Sat, Jan 11, 2020 at 6:15 PM Craig

Hi Stefanus, Thanks for the info. I still think it's a bug though. Take for example a case where the vectors each have four elements. The values in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. So LHSMask[Mask[i]] can go out of bounds, no? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du

As Sanjay noted in D31426<https://reviews.llvm.org/D31426#712701>, InstructionSimplify is missing the following simplification: This function: define <4 x i32> @splat_operand(<4 x i32> %x) { %splat = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> zeroinitializer %shuf = shufflevector <4 x i32> %splat, <4 x i32> undef, <4 x i32>

With LLVM 3.8 the JIT compiler engine generates an AVX512 instruction although I target an 'avx2' CPU (intel Core I7). I just downloaded the most recent 3.8 and still it happens. It happens with this input module: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" define void @module_cFFEMJ(i64 %lo, i64 %hi, i64 %myId, i1 %ordered, i64 %start, i32* noalias align 32

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point

On 06/23/2016 12:56 PM, Craig Topper wrote: > Can you check what value "getHostCPUName" returned? getHostCPUName() = skylake > > On Thu, Jun 23, 2016 at 9:53 AM, Frank Winter via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > With LLVM 3.8 the JIT compiler engine generates an AVX512 > instruction although I

When the uitofp and sitofp instructions convert e.g. from i64 to float, what rounding mode do they use? Answers in the form a patch to LangRef.html would be great! Thanks, Jay.