similar to: [LLVMdev] Exception Problems

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.

On Feb 12, 2007, at 12:58 PM, Evan Cheng wrote: > > On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > >> >> selector refused to select certain ops (specifically stores) for some >> instructions when the operand type wasn't the first type for the >> register class. After some digging around I seem to have solved the >> problem by creating bitconvert

Hi. I am beginning to learn LLVM (using LLVM 2.3.0 on a Linux x86_64 machine) and wanted to check the status of the support of arbitrary size integers. To do so, I tried to modify the HowToUseJIT example by replacing the Int32Ty with another size (let's say 12 bits for the example). While it compiles ok, I get the following assert at run-time: HowToUseJIT: LegalizeDAG.cpp:4059:

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT,

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

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

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

Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in

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 >

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

Thank you so much. it run fine. Can you please resolve following issue; I now have support for v2048i32 but my backend supports v64i32 so ultimately v2048i32 needs to be split into 32 v64i32 instructions. the only difference between 2 is if its orginally v2048i32 i want my registers assignment from REG_A set. if its v64i32 originally, then i want registers from set REG_B. How to accomplish

Evan Cheng wrote: > You need to insert new basic blocks and update CFG to accomplish this. > There is a hackish way to do this right now. Add a pseudo instruction > to represent this operation and mark it usesCustomDAGSchedInserter. > This means the intrinsic is mapped to a single (pseudo) node. But it > is then expanded into instructions that can span multiple basic >

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

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 =

Hi Evan, Evan Cheng wrote: > This does not patch cleanly for me (PPCISelLowering.cpp). Can you > prepare a updated patch? This should work, though I won't have access to my test box now until next Thursday so no guarantees :) Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Index: lib/Target/PowerPC/PPCISelLowering.h

Why are you reverting patches for any area that you have no authorization for ? No build was broken. This patch is fine. I am authorized to check in to the Mips area and Daniel is the maintainer for that area. On 06/08/2014 02:13 AM, Alp Toker wrote: > Author: alp > Date: Sun Jun 8 04:13:42 2014 > New Revision: 210424 > > URL:

I would be very grateful if you specify whether there is some way to allocate registers (different order) / from different register sets to the same instruction based on the vector width/ no of iterations. I have tried several alternatives but could not succeed. Also I have asked this question many times but no one responds. Is there something wrong with this?? Kindly guide me. Thank You On

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List