search for: iscompatible

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

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

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

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 >

Hello everyone, The review http://reviews.llvm.org/D20951 implements initial support for the ARM architecture in LLD. To keep the patch size down, and to avoid the complexities of interworking between ARM and Thumb, there is just enough support for an ARM only Hello World to link and run on ARM Linux [*]. My main aim is to get this functionality committed as the basis of an ARM port and would