search for: sdiselasmoperandinfo

Unlike those happy few who are seeing thousands of visibility warnings, I get only one with gcc 4.3: lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: ‘llvm::SDISelAsmOperandInfo’ declared with greater visibility than the type of its field ‘llvm::SDISelAsmOperandInfo::AssignedRegs’ Anyway know what this is about? Ciao, Duncan.

...(at least I don't think there is, as I'm not too familiar yet with LLVM internals), which meant that I needed to handle multiple alternative constraints in other places besides just SelectionDAGBuilder::visitInlineAsm. Basically I see that there are three layers of contraint info classes, SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. Therefore, I implemented a different scheme, putting a ParseConstraints function in TargetLowering that returns a vector of AsmOperandInfo objects, and which will do the constraint selection without needing the DAG. I'm assuming the value info in the...

Hi Duncan, Does r55922 fix this for you? Dan On Sep 6, 2008, at 10:09 AM, Duncan Sands wrote: > Unlike those happy few who are seeing thousands of visibility > warnings, I get only one with gcc 4.3: > > lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:3889: warning: > ‘llvm::SDISelAsmOperandInfo’ declared with greater visibility than > the type of its field ‘llvm::SDISelAsmOperandInfo::AssignedRegs’ > > Anyway know what this is about? > > Ciao, > > Duncan. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.u...

...: type name first seen using 'struct' now seen using 'class' 1> ..\..\..\llvm\utils\TableGen\TGParser.cpp(33) : see declaration of 'llvm::SubClassReference' 7>..\..\..\..\llvm\lib\CodeGen\SelectionDAG\SelectionDAGBuild.cpp(4636) : warning C4099: 'llvm::SDISelAsmOperandInfo' : type name first seen using 'class' now seen using 'struct' 7> c:\dj\llvm\lib\codegen\selectiondag\SelectionDAGBuild.h(64) : see declaration of 'llvm::SDISelAsmOperandInfo' 14>C:\llvm\include\llvm/Debugger/SourceLanguage.h(32) : warning C4099: 'll...

...he AddrModeMatcher reference. I don't see a DAG pointer either; it seems to be an argument in some places. Regardless, unifying the three loops that do pretty much the same thing is surely a good idea. > Basically I see that there are three layers of contraint info > classes, SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. > Therefore, I implemented a different scheme, putting a > ParseConstraints function in TargetLowering that returns a vector of > AsmOperandInfo objects, and which will do the constraint selection > without needing the DAG. I'm as...

...ference. I don't > see a DAG pointer either; it seems to be an argument in some places. > Regardless, unifying the three loops that do pretty much the same thing is > surely a good idea. > > > Basically I see that there are three layers of contraint info classes, >> SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. Therefore, I >> implemented a different scheme, putting a ParseConstraints function in >> TargetLowering that returns a vector of AsmOperandInfo objects, and which >> will do the constraint selection without needing the DAG. I'm ass...

...ence. > I don't see a DAG pointer either; it seems to be an argument in some > places. Regardless, unifying the three loops that do pretty much > the same thing is surely a good idea. > > > Basically I see that there are three layers of contraint info > classes, SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. > Therefore, I implemented a different scheme, putting a > ParseConstraints function in TargetLowering that returns a vector of > AsmOperandInfo objects, and which will do the constraint selection > without needing the DAG. I'm as...

...9;t see a DAG pointer either; it seems to be an argument in some places. >> Regardless, unifying the three loops that do pretty much the same thing is >> surely a good idea. >> >> >> Basically I see that there are three layers of contraint info classes, >>> SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. Therefore, I >>> implemented a different scheme, putting a ParseConstraints function in >>> TargetLowering that returns a vector of AsmOperandInfo objects, and which >>> will do the constraint selection without needing the DAG....

...ther; it seems to be an argument in some places. >>> Regardless, unifying the three loops that do pretty much the same thing is >>> surely a good idea. >>> >>> >>> Basically I see that there are three layers of contraint info classes, >>>> SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. Therefore, I >>>> implemented a different scheme, putting a ParseConstraints function in >>>> TargetLowering that returns a vector of AsmOperandInfo objects, and which >>>> will do the constraint selection without needi...

...t see a DAG pointer either; it seems to be an argument in >> some places. Regardless, unifying the three loops that do pretty >> much the same thing is surely a good idea. >> >> >> Basically I see that there are three layers of contraint info >> classes, SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. >> Therefore, I implemented a different scheme, putting a >> ParseConstraints function in TargetLowering that returns a vector >> of AsmOperandInfo objects, and which will do the constraint >> selection without needing the...

...argument in some places. >>>> Regardless, unifying the three loops that do pretty much the same thing is >>>> surely a good idea. >>>> >>>> >>>> Basically I see that there are three layers of contraint info classes, >>>>> SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo. Therefore, I >>>>> implemented a different scheme, putting a ParseConstraints function in >>>>> TargetLowering that returns a vector of AsmOperandInfo objects, and which >>>>> will do the constraint selection w...

...er; it seems to be an >>> argument in some places. Regardless, unifying the three loops >>> that do pretty much the same thing is surely a good idea. >>> >>> >>> Basically I see that there are three layers of contraint info >>> classes, SDISelAsmOperandInfo -> AsmOperandInfo -> >>> ConstraintInfo. Therefore, I implemented a different scheme, >>> putting a ParseConstraints function in TargetLowering that returns >>> a vector of AsmOperandInfo objects, and which will do the >>> constraint selection with...

...>>>> argument in some places. Regardless, unifying the three loops >>>> that do pretty much the same thing is surely a good idea. >>>> >>>> >>>> Basically I see that there are three layers of contraint info >>>> classes, SDISelAsmOperandInfo -> AsmOperandInfo -> >>>> ConstraintInfo. Therefore, I implemented a different scheme, >>>> putting a ParseConstraints function in TargetLowering that >>>> returns a vector of AsmOperandInfo objects, and which will do the >>>> constrain...

...pe const*) constin libLLVMSelectionDAG.a(TargetLowering.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMCodeGen.a(MachineFunction.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) llvm::SDISelAsmOperandInfo::getCallOperandValEVT(llvm::LLVMContext&, llvm::TargetLowering const&, llvm::TargetData const*) constin libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) CanCoerceMustAliasedValueToLoad(llvm::Value*, llvm::Type const*, llvm::TargetData const&)in libLLVMScalarOpts.a(GVN.cpp.o)...

...pe const*) constin libLLVMSelectionDAG.a(TargetLowering.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMCodeGen.a(MachineFunction.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) llvm::SDISelAsmOperandInfo::getCallOperandValEVT(llvm::LLVMContext&, llvm::TargetLowering const&, llvm::TargetData const*) constin libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) CanCoerceMustAliasedValueToLoad(llvm::Value*, llvm::Type const*, llvm::TargetData const&)in libLLVMScalarOpts.a(GVN.cpp.o)...