Displaying 12 results from an estimated 12 matches for "getvalueasstr".
2005 Oct 24
0
[LLVMdev] [patch] Fix problems with build LLVM using gcc 4.1.0(gcc CVS mainline)
...std::vector<Record*> Insts = Records.getAllDerivedDefinitions("Instruction");
EmitSourceFileHeader("Machine Code Emitter", o);
- o << "namespace llvm {\n\n";
+ //o << "namespace llvm {\n\n";
std::string Namespace = Insts[0]->getValueAsString("Namespace") + "::";
// Emit function declaration
@@ -256,5 +256,5 @@
<< " return Value;\n"
<< "}\n\n";
- o << "} // End llvm namespace \n";
+ //o << "} // End llvm namespace \n";
}
-Chris...
2007 Feb 05
2
[LLVMdev] automatically generating intrinsic declarations
...kedType::get(";
+ EmitTypeGenerate(OS, ArgType->getValueAsDef("ElTy"));
+ OS << ", " << ArgType->getValueAsInt("NumElts") << ")";
+ } else {
+ OS << "Type::getPrimitiveType(";
+ OS << ArgType->getValueAsString("TypeVal") << ")";
+ }
+}
+
/// RecordListComparator - Provide a determinstic comparator for lists of
/// records.
namespace {
@@ -176,6 +192,43 @@
OS << "#endif\n\n";
}
+void IntrinsicEmitter::EmitGenerator(const std::vector<CodeGenIntrinsi...
2005 Oct 24
2
[LLVMdev] [patch] Fix problems with build LLVM using gcc 4.1.0(gcc CVS mainline)
>> 2) Same error but some diff. problem with AlphaCodeEmitter.cpp and
>> PPCCodeEmitter.cpp:
>>
>> GCC don't like definition member-functions in global namespace with
>> declaration in llvm::<unnamed> :
Sorry for wrong comment.
Must be:
GCC 4.1.0 don't like definition member-functions in llvm namespace with
declaration in
2019 Apr 01
3
Please expose predicates to MachineVerifier
Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.
2014 Mar 13
2
[LLVMdev] MergeFunctions: reduce complexity to O(log(N))
...if (int Res = cmpNumbers(LA.getValueAsInt(), RA.getValueAsInt()))
> + return Res;
> + break;
> + case Other:
> + if (int Res = cmpStrings(LA.getKindAsString(),
> RA.getKindAsString()))
> + return Res;
> + if (int Res = cmpStrings(LA.getValueAsString(),
> RA.getValueAsString()))
> + return Res;
> + break;
> + }
>
> Attributes already have operator< and operator==. Please reuse them.
>
> 0006:
>
> This looks fine.
>
> 0007:
>
> + int cmpGEP(const GEPOperator *GEP1, const GEPOp...
2007 Feb 05
0
[LLVMdev] automatically generating intrinsic declarations
On Mon, 5 Feb 2007, Dan Gohman wrote:
> LLVM knows what all the types of the intrinsic functions are; I thought,
> why are users (including llvm-gcc...) required to duplicate all this
> information in order to use them? I mean in order to call
> getOrInsertFunction to get declarations for them.
That is an excellent question! :) In the bad old days, we used to allow
intrinsics
2007 Feb 06
1
[LLVMdev] automatically generating intrinsic declarations
...ot;ElTy"));
+ OS << ")";
+ } else if (ArgType->isSubClassOf("LLVMEmptyStructType")) {
+ OS << "StructType::get(std::vector<const Type *>())";
+ } else {
+ OS << "Type::getPrimitiveType(";
+ OS << ArgType->getValueAsString("TypeVal") << ")";
+ }
+}
+
/// RecordListComparator - Provide a determinstic comparator for lists of
/// records.
namespace {
@@ -176,6 +198,43 @@
OS << "#endif\n\n";
}
+void IntrinsicEmitter::EmitGenerator(const std::vector<CodeGenIntrinsi...
2014 Sep 19
2
[LLVMdev] More careful treatment of floating point exceptions
Hi Sanjay,
Thanks, I saw this flag and it's definitely should be considered, but
it appeared to me to be static characteristic of target platform. I'm
not sure how appropriate it would be to change its value from a front-end.
It says "Has", while optional flag would rather say "Uses" meaning that
implementation cares about floating point exceptions.
Regards,
Sergey
2014 Sep 25
2
[LLVMdev] More careful treatment of floating point exceptions
...Attribute::MinSize);
+ // Target cares about IEEE754 conformant FP exceptions at run-time?
+ HonorFPExceptions = F.hasFnAttribute("honor-fp-exceptions") &&
+ (F.getFnAttribute("honor-fp-exceptions")
+ .getValueAsString() == "true");
+
/// Builder - This is an IRBuilder that automatically inserts new
/// instructions into the worklist when they are created.
IRBuilder<true, TargetFolder, InstCombineIRInserter>
diff --git a/lib/Transforms/Utils/SimplifyCFG.cpp b/lib/Transforms/Utils/Simpl...
2014 Feb 27
3
[LLVMdev] MergeFunctions: reduce complexity to O(log(N))
Hi Nick,
I tried to rework changes as you requested. One of patches (0004 with
extra assertions) has been removed.
> + bool isEquivalentType(Type *Ty1, Type *Ty2) const {
> + return cmpType(Ty1, Ty2) == 0;
> + }
>
> Why do we still need isEquivalentType? Can we nuke this?
Yup. After applying all the patches isEquivalentType will be totally
replaced with cmpType. All
2016 Jun 27
0
Tail call optimization is getting affected due to local function related optimization with IPRA
Hello ,
To solve this bug locally I have given preference to tail call optimization
over local function related optimization in IPRA. I have added following
method to achieve this:
bool isEligibleForTailCallOptimization(Function *F) {
CallingConv::ID CC = F->getCallingConv();
if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC ==
CallingConv::HiPE)
return true;
return false;
2016 Jun 26
3
Tail call optimization is getting affected due to local function related optimization with IPRA
According to this http://llvm.org/docs/CodeGenerator.html#tail-call-section,
it seems that adding a new CC for the purpose of local function
optimization seems a good idea because tail call optimization only takes
place when both caller and callee have fastcc or GHC or HiPE calling
convention.
-Vivek
On Sun, Jun 26, 2016 at 1:26 AM, vivek pandya <vivekvpandya at gmail.com>
wrote:
>