search for: armconstantpoolvalu

ArmConstantPoolValue is derived from MachineConstantPoolValue Is there some reason for this? Some advantage?

...MPCLabelIndex; + /// ARMJumpTableIndex - Keep track of the number ofJump Tables + unsigned ARMJumpTableIndex; SDValue LowerMemOpCallTo(CallSDNode *TheCall, SelectionDAG &DAG, const SDValue &StackPtr, const CCValAssign &VA, Index: lib/Target/ARM/ARMConstantPoolValue.h =================================================================== --- lib/Target/ARM/ARMConstantPoolValue.h (revision 72728) +++ lib/Target/ARM/ARMConstantPoolValue.h (working copy) @@ -25,6 +25,7 @@ enum ARMCPKind { CPValue, CPNonLazyPtr, + CPDataSegmentJumpTable, CPStub...

...nctionInfo>(); SDValue UId = DAG.getConstant(AFI->createJumpTableUId(), PTy); SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy); #if 1 // @@ GET TABLE BASE: current code Table = DAG.getNode(ARMISD::WrapperJT, MVT::i32, JTI, UId); #else // @ MY ATTEMPT AT MOVING THIS OUT ARMConstantPoolValue *CPV = new ARMConstantPoolValue("a_jump_table", 666); SDValue TableValue = DAG.getTargetConstantPool(CPV, PTy, 2); SDValue CPAddr = DAG.getNode(ARMISD::Wrapper, MVT::i32, TableValue); Table = DAG.getLoad(PTy, dl, DAG.getEntryNode(), CPAddr, NULL, 0); #endif Index = DAG.getNode(I...

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

...mber of ARM PC labels created. unsigned ARMPCLabelIndex; + /// ARMJumpTableIndex - Keep track of the number ofJump Tables + unsigned ARMJumpTableIndex; void addTypeForNEON(MVT VT, MVT PromotedLdStVT, MVT PromotedBitwiseVT); void addDRTypeForNEON(MVT VT); Index: lib/Target/ARM/ARMConstantPoolValue.h =================================================================== --- lib/Target/ARM/ARMConstantPoolValue.h (revision 74072) +++ lib/Target/ARM/ARMConstantPoolValue.h (working copy) @@ -25,6 +25,7 @@ enum ARMCPKind { CPValue, CPNonLazyPtr, + CPDataSegmentJumpTable, CPStub...

I had some problems adding the address of a jump table to the constant pool. The problem is that the address of a jump table is not a GlobalValue.Currently I decided to expand BRIND so that I can work on simpler problems :-) A small brain dump on the issue: GlobalValues are currently used to represent functions and global variables. Maybe we could also use then for anything that will have a label

...use the existing LLVM code for this. Why did you change the default value for JumpTableDataSection? Jump tables really should not go into .data. That is a security hole. They should be read-only. When you create global symbols for the jump tables, you specify a ".T" name: new ARMConstantPoolValue(".T", Num, ARMCP::CPDataSegmentJumpTable); Why ".T"? And, by the way, I noticed that you removed a "blank" comment line in ARMISelLowering.h. I think I have done that myself, but I recently discovered that the extra lines are intentional. Doxygen recognizes C+...

...I am not sure where .rodata lives. if it lives in the text *segment* you get better protection but the code wont be PIC if .rodata goes into the data segment it is the other way round. > When you create global symbols for the jump tables, you specify a ".T" > name: > > new ARMConstantPoolValue(".T", Num, ARMCP::CPDataSegmentJumpTable); > > Why ".T"? > T as in Table, I do not care much about the naming. If you have a better proposal I will go with that. > > And, by the way, I noticed that you removed a "blank" comment line in > ARMISelLow...