search for: getsrcti

Hi Nick, I parsed your message again carefully and did some experiments. I guess the: for (User::op_iterator i = I->op_begin(), e = I->op_end(); i != e; ++i) { } iterates over the operands of the instruction "I", which are as you said, *other* instructions. But if I want to get other information about the instruction, say the type of the operands, then I still need to figure

ivtm wrote: > Hey Oscar, > > I want to extract information from the instruction. > > Think writing a simple interpreter. > > I already have the CallInst instance (described above in the message). > > Via ci->getOperand(1) say I can get the 'i32 8' parameter and I can get the > 'i32' and '8' separately as Nick described. > > But I

On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html

Hi Nick, Perhaps I am confused. What is the best way to extract information from instructions ? Is it via the, say: for (User::op_iterator i = I->op_begin(), e = I->op_end(); i != e; ++i) .... I am not sure what happens next, e.g. to the variable 'i', you should know what part of the instruction this is and cast it to the necessary type. For example, I am parsing the

Tobias, I've attached an updated patch. It contains a few bug fixes and many (refactoring and coding-convention) changes inspired by your comments. I'm currently trying to fix the bug responsible for causing a compile failure when compiling test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the pass begins to fuse instructions in a basic block in this file, the aliasing

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

Tobias, I've attached an updated copy of the patch. I believe that I accounted for all of your suggestions except for: 1. You said that I could make AA a member of the class and initialize it for each basic block. I suppose that I'd need to make it a pointer, but more generally, what is the thread-safely model that I should have in mind for the analysis passes (will multiple threads

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

Hi Matthijs, Thanks for giving some code so we can discuss this in more concrete detail. In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: > On 11/23/2011 05:52 PM, Hal Finkel wrote: > > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > >>> > > Tobias, > >>> > > > >>> > > I've attached an updated patch. It contains a few bug fixes

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli