similar to: [LLVMdev] [llvm-commits] [llvm] r79731 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp

Well, I found out the reason why this assert is here, and this is problematic. CondCodeActions only supports up to 32 different value types. Since we are past 32, what LLVM has is broken. Currently the 4 different Legalize states are stored in successive bits and packed into a uin64_t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// LegalizeAction

On Thu, 26 Jul 2012 21:15:35 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Well, I found out the reason why this assert is here, and this is > problematic. > > CondCodeActions only supports up to 32 different value types. Since > we are past 32, what LLVM has is broken. > > Currently the 4 different Legalize states are stored in successive >

Yeah just the ordering are the real difference. Also, I use shifts and masks instead of conditionals and modules. My patch is attached. For me either patch is fine, but what LLVM has now is broken. Either patch is fine, just need approval from someone to submit. Micah > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Thursday, July 26, 2012 2:39 PM

I'm trying to understand why this assertion is here. LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < sizeof(CondCodeActions[0])*4 && "Table isn't big enough!"); LegalizeAction Action = (LegalizeAction)

Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way. That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that. while (SVT != MVT::f32) {

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

Here there is the dump: SelectionDAG.cpp:81: static bool llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, const llvm::APFloat &): Assertion `VT.isFloatingPoint() && "Can only convert between FP types"' failed. 0 libLLVMSupport.so 0x00007f7405022de5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1 libLLVMSupport.so 0x00007f74050232e3 2 libpthread.so.0

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah

This code lives in DAGCombiner.cpp: ------------- // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr' if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) { // NOTE: If the original store is volatile, this transform must not increase // the number of stores. For example, on x86-32 an f64 can be stored in one // processor operation but

v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not

In the current trunk, System/Atomic.[h,cpp] define void llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in <windows.h> and (since it's a preprocessor macro, and not a scoped function definition) causes the sys::MemoryFence definition on Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl intrinsic (_mm_mfence). This breaks the Visual Studio build.

On May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote: > In the current trunk, System/Atomic.[h,cpp] define void > llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's

Owen Anderson wrote: > Is this actually the case? I can't find it documented anywhere on > MSDN or the rest of the internet. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F MemoryFence WinNT.h 2231:#define MemoryFence _mm_mfence C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F MemoryBarrier WinNT.h 2288:#define MemoryBarrier __faststorefence

Hi, if I write the following simple program: target datalayout = "e-p:64:64:64-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-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" define void @foo () { %1 = alloca half store half 0xH42CC, half* %1 ; 0xH42CC = 3.4 %2 = load half* %1

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

I searched the archives and found this from last month: I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== ---

Is this actually the case? I can't find it documented anywhere on MSDN or the rest of the internet. --Owen On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the

Hi everybody. I use to work with monthly data, however this is my first time working with weekly data. I have 4 data bases with monthly data and 1 with weekly data, so I want to convert my weekly to monthly data in order to have the same periodicity in all of them. I've read that package xts can help me with this issue, so I have done the following script:

I tried checking out the latest llvm/clang from SVN (as of a few hours ago) and compiling it (clang 3.6.1 doesn't compile 3.7 because it fails a version check, so I repeated the technique of compiling with Microsoft C++ first, then using the resulting clang-cl.exe). It fails with a bunch of error messages along the lines of: LLVMSupport.lib(Atomic.obj) : error LNK2019: unresolved external