search for: x86iselsimpl

...e > would be happy to apply it. Continuing improvements in the code > generator should eventually make this kind of thing fall out > automatically, but for now they must be implemented manually. > > -Chris I succumbed to temptation and made the improvement. Diffs are attached for X86ISelSimple.cpp and X86InstrBuilder.h. I determined that the reason two instructions are generated in the first place, instead of being folded immediately into one, is because locals do not have a physical offset assigned at that time. There is a peephole optimization pass after the stack frame is finalized...

On Thu, 26 Aug 2004, Jeff Cohen wrote: > There seems to be a disadvantage to the approach of allocating all > locals on the stack using alloca. Consider the following code: There is nothing intrinsic in LLVM that prevents this from happening, we just have not yet implemented 'stack packing'. > We have two arrays, b and c, only one of which can exist at any given > time.

There seems to be a disadvantage to the approach of allocating all locals on the stack using alloca. Consider the following code: extern void func(int*); extern int xyz(); void abc() { int a = xyz(); int i; { int b[10]; for (i = 0; i < 10; i++) b[i] = xyz(); func(b); } { int c[10]; for (i = 0; i < 10; i++) c[i] = xyz(); func(c); } func(&a); } We have two arrays,

...ode is expanded to a call if it's not directly supported for the target. To illustrate what I have been doing so far I attach the diff to this mail -- if someone could have a look at it and tell me what needs to be done to get it working I would be very grateful... (Note that if you use the X86ISelSimple it's already working...) m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: temp.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050311/ee9c30d4/attachment.ksh>

...se FP instructions. As an example, in the following function the sub abs and compare compiles to 13 instructions! Also it has changed the result of the abs to be a 64 bit double when it stores it, while my intention was to get a 32 bit float. For comparision I included the code generated by the X86ISelSimple which is only 8 instructions... it seems the compare is being generated twice in two different ways with the pattern selector?! I also attached the diff of my current version m. internal void %EvaluatePoint3D65() { EntryBlock: store float 0.000000e+000, float* getelementptr ([4 x float]* cas...

On Thu, 9 Sep 2004 08:52:10 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > > I haven't got around to this yet but I will. The odds are good the > > problem is in a BSD system header file so I need to capture the > > preprocessed source. > > I guess not... the file 2004-01-01-UnknownInitSize.c does not include > anything else, so there is no preprocessed

> I haven't got around to this yet but I will. The odds are good the > problem is in a BSD system header file so I need to capture the > preprocessed source. I guess not... the file 2004-01-01-UnknownInitSize.c does not include anything else, so there is no preprocessed source to capture...

...Continuing improvements in the code > > generator should eventually make this kind of thing fall out > > automatically, but for now they must be implemented manually. > > > > -Chris > > I succumbed to temptation and made the improvement. Diffs are attached > for X86ISelSimple.cpp and X86InstrBuilder.h. > > I determined that the reason two instructions are generated in the first > place, instead of being folded immediately into one, is because locals > do not have a physical offset assigned at that time. There is a > peephole optimization pass after the...

Chris Lattner wrote: > Note that packed support in LLVM is not complete yet. In > particular, here are some of the big missing pieces: > > 1. No code generators can generate vector instructions yet (SSE or > altivec, for example). This should be fairly easy to add though. > 2. The lowerpacked pass, which currently converts packed ops into their > scalar counterparts,

...and lib/CodeGen/IntrinsicLowering.cpp for other isels. > To illustrate what I have been doing so far I attach the diff to this mail -- > if someone could have a look at it and tell me what needs to be done to get > it working I would be very grateful... (Note that if you use the > X86ISelSimple it's already working...) One of the problems that jumps out at me in the pattern version is that you have code that looks like this: + case Intrinsic::sqrt: + setValue(&I, DAG.getNode(ISD::FP_SQRT, MVT::f64, + getValue(I.getOperand(1)))); In your c...

....h Index: lib/Target/SparcV9/RegAlloc/PhyRegAlloc.cpp Index: lib/Target/SparcV9/RegAlloc/PhyRegAlloc.h Index: lib/Target/SparcV9/RegAlloc/RegClass.cpp Index: lib/Target/SparcV9/RegAlloc/RegClass.h Index: lib/Target/X86/X86AsmPrinter.cpp Index: lib/Target/X86/X86ISelPattern.cpp Index: lib/Target/X86/X86ISelSimple.cpp Index: lib/Target/X86/X86PeepholeOpt.cpp Index: lib/Target/X86/X86RegisterInfo.cpp Index: lib/Target/X86/X86TargetMachine.cpp Index: lib/Transforms/Instrumentation/EmitFunctions.cpp Index: lib/Transforms/Instrumentation/TraceBasicBlocks.cpp Index: lib/Transforms/Instrumentation/TraceValues.cpp...

...cked : FAIL , expected PASS Native assembly file /usr/home/llvm/obj/test/tmp/feature-mc-packed.ll.s was not created; error output was: Assertion failed: (0 && "Invalid type to getClass!"), function getClass, file /usr/home/llvm/lib/Target/X86/X86ISelSimple.cpp, line 65. Abort trap (core dumped) I've filed a bug for the ICEs.

...; > <File > RelativePath="..\..\lib\Target\X86\X86InstrInfo.cpp"> > </File> > <File > RelativePath="..\..\lib\Target\X86\X86ISelPattern.cpp"> > </File> > <File > RelativePath="..\..\lib\Target\X86\X86ISelSimple.cpp"> > </File> > <File > RelativePath="..\..\lib\Target\X86\X86JITInfo.cpp"> > </File> > <File > RelativePath="..\..\lib\Target\X86\X86PeepholeOpt.cpp"> > </File> > <File > Relati...