search for: asmoperandinfo

..., llvm::Value*, llvm::DenseMapInfo<llvm::Value*>, llvm::DenseMapInfo<llvm::Value*> >&)’: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: 966: error: no matching function for call to ‘llvm::TargetLowering::ComputeConstraintToUse (llvm::TargetLowering::AsmOperandInfo&, llvm::SDValue) const’ /Volumes/mrs5/net/llvm/llvm/include/llvm/Target/TargetLowering.h:1177: note: candidates are: virtual void llvm::TargetLowering::ComputeConstraintToUse (llvm::TargetLowering::AsmOperandInfo&, llvm::SDValue, bool, llvm::SelectionDAG*) const make[3]: *** [/Volume...

...east 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...

...rModeMatcher 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...

...e. 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...

...> 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...

...e 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....

...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...

...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...

...nt 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...

...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...

...t;>> 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...