similar to: [LLVMdev] direct register mapping to variables

Hi, I'm trying to annotate the final assembly output of my llvm codegen with the corresponding input C statements. It would've been super easy if the source information were included in the IR debug info. But obviously they are not, and there are good reasons why not ! So I'm bound to collecting all my information in the back-end from the existing debug pseudo instructions. As you

Hi I'm referencing the method: Lib/Transforms/Instrumentation/InstrProfiling.cpp:InstrProfiling::lowerCoverageData() At the end of the function, why is the variable being placed in __llvm_prf_names section? Shouldn't it be placed in __llvm_covmap section? Thanks Ali -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I'm trying to implement an overloading behavior to some of our builtin functions, and came across the following comment in SemaExpr.cpp // Check for overloaded calls. This can happen even in C due to extensions. If (Fn->getType() == Context.OverloadTy) { .... I was wondering which C extensions is this referring to? Thanks Ali -------------- next part -------------- An HTML attachment

Hi Ali, I assume this is primarily for interrupt function handling? If so, I have a few ideas to bounce your direction if you're interested. -j On Aug 6, 2009, at 3:32 PM, Alireza.Moshtaghi at microchip.com wrote: > I need to perform call graph analysis (after all modules are merged) > to > find which function calls which, and depending on the attributes that > each

On Mar 31, 2009, at 11:46 AM, Alireza.Moshtaghi at microchip.com wrote: > Any thoughts on this? > I would like to get it right before jumping into the nuts and bolts > of it…. Did you see this Ali? http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL:

ExpandOp is not called at all. In SelectionDAGLegalize::HandleOp() only the ValueType is considered in the switch statement to decide if it is legal or promote or expand. As I trace back (correct me if I'm wrong) these values are set in TargetLowering::computeRegisterProperties() and it is based on the largest register class (in my case the smallest possible pointer size, 16-bit) So it reduces

What is the reason for getelementptr being tied to only 32 or 64 bit indexes? It seems to me that integer size would be better choice... Anyways, this is getting in our way. What is your suggestion? Thanks Ali > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Chris Lattner > Sent: Monday, August 18, 2008 4:33

Correction: The analysis I made regarding the callers knowledge of sign/zero extension of return value is flawed. So I take it back. Never the less, I don't see how adding attributes would resolve this problem either. Ali ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alireza.Moshtaghi at microchip.com

> On further reflection, I actually like the idea of adding 4 attributes > better than adding knowledge of "int" into TargetData. "int" is a C > notion that doesn't really belong in TargetData, and it is better for > the optimizers to have the front-end expose the implicit promotions. This is very true and indeed applicable to this problem... So I have to

Is this something that will happen in future? Or there is no plan for it? Thanks, Ali -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, April 02, 2008 10:30 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Retrieving local variable names. It's not currently available. LLVM would have to

On Apr 2, 2008, at 1:33 PM, Alireza.Moshtaghi at microchip.com wrote: > Is this something that will happen in future? Or there is no plan for > it? I am not aware of any plan to add this. I suspect this won't happen until there is a major push to improve debugging support. If you are interested in this area, feel free to contribute! :-) Evan > > > Thanks, > Ali >

Evan, The machine is 8 bit, and of course all registers are 8-bit too. Memory access on this machine is a bit different. The memory is banked into banks of 256-byte, and you can select the active bank using a bank select register. All instructions can access the memory with an 8-bit operand, so in that sense the address space can be viewed as 256-byte long. On the other hand, there are three

On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote: > In this thread I’m trying to merge two email threads into one, > because both discuss the same problem that’s troubling us and I > would like to reach a conclusion on what would be the best approach. > To minimize the size of this thread I only mention the subject of > the other two threads: > (1)

Any thoughts on this? I would like to get it right before jumping into the nuts and bolts of it.... Thanks ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alireza.Moshtaghi at microchip.com Sent: Thursday, March 12, 2009 10:39 AM To: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] promotion of return value.

In this thread I'm trying to merge two email threads into one, because both discuss the same problem that's troubling us and I would like to reach a conclusion on what would be the best approach. To minimize the size of this thread I only mention the subject of the other two threads: (1) [LLVMdev] Integer promotion of return node operand (initiated by Sachin) (2) [LLVMdev] trouble

On May 29, 2008, at 10:30 AM, Alireza.Moshtaghi at microchip.com wrote: > > > 4) There will be 4 new function attributes: > sign_ext_from_i8, sign_ext_from_i16 > zero_ext_from_i8, zero_ext_from_i16 > These attributes will be placed on the function CALL node by > front-end > to inform the backend about such promotions and enable optimization > of > return

I need to perform call graph analysis (after all modules are merged) to find which function calls which, and depending on the attributes that each function has and what functions call it, I may need to clone it and modify some of calls to that function to call the cloned function. Currently we are doing this in few acrobatic moves that span from an llvm-ld pass (to do call graph analysis) all the

Chris, Extending LLVM IR to support PointerTypes that take an address space is what I was hoping to avoid. However, if we want to do things right, that is probably the way to go. Now that we got here, let me write some of my thoughts on this and solicit your input: --- 1) Syntax extension: In our existing compiler for 8-bit microcontrollers, we have introduced rom and ram qualifiers (with ram

Thank you Chris, I had the pointer size wrong. I fixed it and now it passes that point as expected :) which takes me to a second question: The processor that I am working on is 8-bit and has Harvard architecture; this implies different pointer types (sizes) to objects in data memory or program memory (functions or data in program memory) At this moment, I am just using only one pointer size

On Mon, Apr 15, 2013 at 3:17 PM, Alireza Moshtaghi < Alireza.Moshtaghi at synopsys.com> wrote: > Hi, > I'm trying to annotate the final assembly output of my llvm codegen with > the corresponding input C statements. > It would've been super easy if the source information were included in the > IR debug info. But obviously they are not, and there are good reasons why