similar to: [LLVMdev] Finding all ConstantFP

Hi, I'm currently trying to translate LLVM IR language to VPO .dec file specification. I'm using LLVM source parser in the same way that it is used in tools llc or llvm-as. One issue I'm having is I cannot find any static values. For example, in a global declaration i.e. '@a = global i32 7, align 4' I cannot get '7' from the parsed structure. Similarly (sort

Hi, What I'm currently working on is a translation from LLVM IR to a register transfer list format used in VPO. If my understanding of ConstantExpr is correct, that they can be evaluated at compile-time, how can I simply have them be evaluated but have the code still remain in IR format? For example, in: store i32 1, i32* getelementptr [6 x i32]* @arr, i32 0, i32 0 the getelementptr

Working with the LLVM source, if I have an Instruction object by itself (created by parsing a module using LLVM's parser), is there a way to get its operands/destination? e.g. '%add = add nsw i32 %tmp2, %tmp1' Being able to get some form of %add, %tmp2, and %tmp1? All I can pull is the operation itself, i.e. that it's an add. Thanks, Brandon

Looking through this mailing list's archives, I've found that the most common fix attempted for removing phi instructions is to use the reg2mem pass. However I'm also finding that this does no guarantee the removal of all phi instructions. I want to write a pass to remove phi instructions without changing register/memory usage. Does this sort of translation of phi

Hi, I was wondering how exactly LLVM handles the ConstantExpr, specifically GEP ConstantExpr, in code generation. From what I'm reading, translating these Constant Expressions into Instructions can slow the code, so I'd like to be able to handle ConstantExpr in the same way that LLVM code generation does. Thanks, Brandon

Let's say I have the following IR code: 21> %tmp = load i32* @myrand.z, align 4 22> %tmp1 = and i32 %tmp, 5535 23> %tmp2 = mul nsw i32 %tmp1, 36969 24> %tmp3 = ashr i32 %tmp, 16 And I have an Instruction *inst that is the instruction on line 22. then have the code: Use *operand1 = &(inst->getOperandUse(0)); I expect that operand1->getNext() will return the the Use*

EDIT: I originally wrote this as a response to this thread (http:// groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/ a735c534f89fc5cf/8d8546811cae5ee8), but it wouldn''t let me respond that that thread (presumably because of it''s age). Rather than just throw it away, I figured I''d post it here in case in can help anyone else. I built a little class to

Teja, I just checked my version of llc to make sure it worked on arm and x86_64 respectively. The website llvm.org hosts a manual page for this tool at http://llvm.org/docs/CommandGuide/llc.html. I think this tool from the ample LLVM armory will accomplish what you are looking to do. All the best in your endeavors, Shaun Shaun Hubbard On Mar 7, 2013, at 10:39 PM, teja tamboli

hi Jay, Consult a local statistician. Statistics is not you think is (namely simple computations, R and probably plotting..). regards, vito Jay Zola <jayjay.1988 at hotmail.nl> ha scritto: > Hello, > > > I am medical student, writing a meta-analysis on complication and > reoperation rates after the five most common treatments of distal > radius fractures. I have

Hello, I am medical student, writing a meta-analysis on complication and reoperation rates after the five most common treatments of distal radius fractures. I have been busy with the statistics for months by my self, but find it quite hard since our classes were very basic. Now I want to compare the treatment modalities to see if there are significant differences. Using R I was able to

----- Original Message ----- > Hi, > > I noticed that ConstantFP::get automatically returns the > appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check whether it is either

I just ran into this today with x86-64: Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> As far as I can tell, DAGCombiner comes along and sees an sint_to_fp of the constant 1 and hapilly folds it into a ConstantFP<1>. ISel then blows up because there's no pattern for it. Does this look familiar to anyone? I don't see any relevant bugs in the database.

I'm working on a project with a machine language for a statically pipelined architecture. This article provides an overview of the idea: http://www.cs.fsu.edu/~whalley/papers/cal11.pdf. Right now, we're using the VPO compiler to produce this assembly code. We've been exploring using LLVM as a front-end to provide high level optimization. We'd like to know if there's a good

What is the proper way to get the bit pattern associated with a ConstantFP? The 32 bit pattern if MVT::f32 or pair of 32 bit patterns with MVT::f64 ? Tia. Reed

Hi, I want to create a double constant from a float constant, here's my code: auto* constFloat1 = static_cast<llvm::ConstantFP*>(llvm::ConstantFP::get(llvm::Type::getFloatTy(context), 3.1)); assert(constFloat1->getType() == llvm::Type::getFloatTy(context)); auto* constFloat2 = llvm::ConstantFP::get(llvm::Type::getDoubleTy(context), constFloat1->getValueAPF());

Hi All, At some point in the next week or two I'm going to remove the ConstantFP::get(type, APFloat) method. Right now, you can immediately fix your code by dropping the first 'type' argument. For example, if you have: ConstantFP::get(Ty, APFloat(1.0)) just change it to: ConstantFP::get(APFloat(1.0)) Both forms work with SVN head right now so you can migrate as

On Mon, Jul 22, 2013 at 10:19 AM, Stephen Lin <swlin at post.harvard.edu> wrote: > Hi, > > I noticed that ConstantFP::get automatically returns the appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e.,

On Sep 24, 2008, at 5:11 PM, David Greene wrote: > I just ran into this today with x86-64: > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > of the > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > blows up > because there's no pattern for it. > >

Dear Vito, Thank you for your reply. I tried to contact the statistics departement numerous times, but did not receive any reply. That is why I started to look on the internet for help. Yours sincerely, Jay Verstuurd vanaf mijn iPhone > Op 26 jun. 2017 om 22:05 heeft Vito Michele Rosario Muggeo <vito.muggeo at unipa.it> het volgende geschreven: > > hi Jay, > Consult a local

SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt (); I can't easily override this in target specific code. Can anyone see an issue with submitting the patch to upstream? Suggestions for an in tree target that could trigger this would be very welcome. Cheers -------------- next part