Displaying 20 results from an estimated 20 matches for "mcurti".
Did you mean:
mcurtis
2012 Oct 03
0
[LLVMdev] adding support for -ffixed-<reg>
On Oct 2, 2012, at 7:23 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support.
It would be great to hav...
2012 Dec 20
2
[LLVMdev] [PATCH] Teaching ScalarEvolution to handle IV=add(zext(trunc(IV)), Step)
...eve) correct for %conv2.
The intent of the patch is to construct the correct (evaluatable)
expression for %result.03 being fed into the computation of %conv2.
Does that make more sense?
Matthew C.
On 12/18/2012 12:54 PM, Dan Gohman wrote:
> On Tue, Dec 18, 2012 at 9:56 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
>> Here's how I'm evaluating the expression (in my head):
>>
>> 00: Add(ZeroExtend(Truncate(Minus(AddRec(Start=0,Step=3)[n],3), i8), i32),3)
>> |
>> 01: Add(ZeroExtend(Trunc...
2012 Dec 18
2
[LLVMdev] [PATCH] Teaching ScalarEvolution to handle IV=add(zext(trunc(IV)), Step)
Dan,
Thanks for the response ...
On 12/17/2012 1:53 PM, Dan Gohman wrote:
> On Mon, Dec 10, 2012 at 2:13 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
>> Hello all,
>>
>> I wanted to get some feedback on this patch for ScalarEvolution.
>>
>> It addresses a performance problem I am seeing for simple benchmark.
>>
>> Starting with this C code:
>>
>> 01: signed char...
2012 Dec 21
0
[LLVMdev] [PATCH] Teaching ScalarEvolution to handle IV=add(zext(trunc(IV)), Step)
On Thu, Dec 20, 2012 at 8:36 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
> Ok, so I think I've mis-represented what's really happening.
> Ignore my previous statements concerning %add :)
>
> Again, given:
>
> 05: for.body: ; preds = %entry,
> %for.body
> 06: %j.04 =...
2012 Oct 02
5
[LLVMdev] adding support for -ffixed-<reg>
I'm adding support for -ffixed-<reg>
<http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435>
for Hexagon and was wondering if I should do it in such a way that other
targets get the support as well by default or if a given target back-end
should have to explicitly opt-in for support.
Any opinions?
Matthew Curtis.
--
Qualcomm Innovation Center,
2012 Dec 18
0
[LLVMdev] [PATCH] Teaching ScalarEvolution to handle IV=add(zext(trunc(IV)), Step)
On Tue, Dec 18, 2012 at 9:56 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
>
> Here's how I'm evaluating the expression (in my head):
>
> 00: Add(ZeroExtend(Truncate(Minus(AddRec(Start=0,Step=3)[n],3), i8), i32),3)
> |
> 01: Add(ZeroExtend(Truncate(Minus(AddRec...
2012 Sep 10
3
[LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 4:08 PM, Chandler Carruth wrote:
> On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org
> <mailto:mcurtis at codeaurora.org>> wrote:
>
> Hello all,
>
> For the hexagon target, we have a couple of tests that are failing
> due to variations in the order of checked text. In these cases the
> ordering is not directly releva...
2012 Sep 07
0
[LLVMdev] teaching FileCheck to handle variations in order
On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org>wrote:
> Hello all,
>
> For the hexagon target, we have a couple of tests that are failing due to
> variations in the order of checked text. In these cases the ordering is not
> directly relevant to the functionality being tested.
>
> For example:
>
&...
2012 Dec 17
0
[LLVMdev] [PATCH] Teaching ScalarEvolution to handle IV=add(zext(trunc(IV)), Step)
On Mon, Dec 10, 2012 at 2:13 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
> Hello all,
>
> I wanted to get some feedback on this patch for ScalarEvolution.
>
> It addresses a performance problem I am seeing for simple benchmark.
>
> Starting with this C code:
>
> 01: signed char foo(void)
> 02: {
> 03: cons...
2012 Sep 10
0
[LLVMdev] teaching FileCheck to handle variations in order
...uiuc.edu] On Behalf Of Matthew Curtis
Sent: Monday, September 10, 2012 9:28 AM
To: Chandler Carruth
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 4:08 PM, Chandler Carruth wrote:
On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
Hello all,
For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested.
For example:
; CHECK: memw(##a)
; CHECK: memw(##b)...
2012 Sep 19
2
[LLVMdev] FileCheck for instructions of indeterminate order?
To test some recent changes, I need to verify that seven instructions
are generated. However, the order of those instructions doesn't matter
(they are all independent loads from memory). Is there a way to tell
FileCheck to reset its scan position rather than assuming all CHECK:
instructions must be in the given order?
My initial version of the test was to use -O0, attempting to ensure that
2012 Dec 10
3
[LLVMdev] [PATCH] Teaching ScalarEvolution to handle IV=add(zext(trunc(IV)), Step)
...rence,
but essentially the same.
Thoughts?
Matthew C.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
-------------- next part --------------
>From e9ca53595ee7a274308c823d14cccd5a8598814d Mon Sep 17 00:00:00 2001
From: Matthew Curtis <mcurtis at codeaurora.org>
Date: Mon, 3 Dec 2012 17:25:20 -0600
Subject: [PATCH] Teach ScalarEvolution to handle IV=add(zext(trunc(IV)),
Accum)
Code generated for 8-bit and 16-bit induction variables commonly
produces this pattern (on hexagon), where the add is performed as a
32-bit operation, but is...
2012 Sep 13
2
[LLVMdev] teaching FileCheck to handle variations in order
...uiuc.edu] On Behalf Of Matthew Curtis
Sent: Monday, September 10, 2012 9:28 AM
To: Chandler Carruth
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 4:08 PM, Chandler Carruth wrote:
On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
Hello all,
For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested.
For example:
; CHECK: memw(##a)
; CHECK: memw(##b)...
2012 Sep 07
5
[LLVMdev] teaching FileCheck to handle variations in order
Hello all,
For the hexagon target, we have a couple of tests that are failing due
to variations in the order of checked text. In these cases the ordering
is not directly relevant to the functionality being tested.
For example:
; CHECK: memw(##a)
; CHECK: memw(##b)
%0 = load i32* @a, align 4
%1 = load i32* @b, align 4
requires that the compiler emit the memory operations for
2012 Oct 15
3
[LLVMdev] ValueTracking's GetUnderlyingObject vs. ScheduleDAGInstrs' getUnderlyingObject
Hello all.
I'm investigating a problem with "Machine Instruction Scheduling" that
is rooted in incorrect alias information.
Things go wrong in the "Merge disjoint stack slots"[1] pass when a store
instruction fails to get updated after its stack slot is merged. As a
result, when "Machine Instruction Scheduling" runs, it incorrectly
re-orders the store and a
2012 Sep 13
0
[LLVMdev] teaching FileCheck to handle variations in order
...2012 9:28 AM
> *To:* Chandler Carruth
> *Cc:* llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] teaching FileCheck to handle variations in order*
> ***
>
> ** **
>
> On 9/7/2012 4:08 PM, Chandler Carruth wrote:****
>
> On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org>
> wrote:****
>
> Hello all,
>
> For the hexagon target, we have a couple of tests that are failing due to
> variations in the order of checked text. In these cases the ordering is not
> directly relevant to the functionality being tested.
>
> For ex...
2012 Oct 02
2
[LLVMdev] adding support for -ffixed-<reg>
On 10/2/2012 9:36 AM, 陳韋任 (Wei-Ren Chen) wrote:
> On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote:
>> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should
>> do it in such a way that other targets get the support as well by default or if
>> a given target back-end should have to explicitly opt-in for support.
> What
2013 Feb 04
0
[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
On 1/31/2013 9:07 PM, 陳韋任 (Wei-Ren Chen) wrote:
> On Wed, Jan 30, 2013 at 12:02:47PM -0600, Matthew Curtis wrote:
>> Hello all,
>>
>> In the process of porting the Polly plug-in to Windows we encountered a couple
>> of issues stemming from the use (within Polly) of global data from LLVM.
>>
>> By far the most common occurrence of this is the definition by a
2013 Jan 30
3
[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
Hello all,
In the process of porting the Polly plug-in to Windows we encountered a
couple of issues stemming from the use (within Polly) of global data
from LLVM.
By far the most common occurrence of this is the definition by a class
of a publicly accessible static ID, the address of which is used to
uniquely identify the class. For example
class AliasAnalysis {
public:
2012 Sep 07
1
[LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 12:12 PM, Krzysztof Parzyszek wrote:
> On 9/7/2012 7:20 AM, Matthew Curtis wrote:
>>
>> The attached patch implements one possible solution. It introduces a
>> position stack and a couple of directives:
>>
>> * 'CHECK-PUSH:' pushes the current match position onto the stack.
>> * 'CHECK-POP:' pops the top value off of the stack