Displaying 20 results from an estimated 800 matches for "philipream".
Did you mean:
philipreames
2020 Feb 24
2
New atomic handling status
> On Jan 22, 2020, at 19:49, Philip Reames <listmail at philipreames.com> wrote:
>
> In short, I hit a major stumbling block. I hadn't account for the fact that some atomic stores dependent on element type (float vs int for instance) for legality.
I think this qualifies as a target/infrastructure bug. It should always be legal to cast the FP atomic...
2013 Dec 16
3
[LLVMdev] Float undef value propagation
On 12/14/2013 05:18 PM, Dan Gohman wrote:
> On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com
> <mailto:resistor at mac.com>> wrote:
>
>
> On Dec 12, 2013, at 4:57 PM, Philip Reames
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>> undef + any == NaN (since undef can be NaN) or undef + any (since
>> undef could be zero)
>
> undef + non-NaN is still undef. The compiler is free to choose any
> value of the type it wishes w...
2013 Dec 16
0
[LLVMdev] Float undef value propagation
On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames <listmail at philipreames.com>wrote:
> On 12/14/2013 05:18 PM, Dan Gohman wrote:
>
>> On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com
>> <mailto:resistor at mac.com>> wrote:
>>
>>
>> On Dec 12, 2013, at 4:57 PM, Philip Reames
>> <list...
2020 May 19
3
LV: predication
...ication.
Cheers,
Sjoerd.
________________________________
From: Simon Moll <Simon.Moll at EMEA.NEC.COM>
Sent: 19 May 2020 09:56
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <listmail at philipreames.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sander De Smalen <Sander.DeSmalen at arm.com>; hanna.kruppe at gmail.com <hanna.kruppe at gmail.com>
Subject: Re: [llvm-dev] LV: predication
Hi Sjoerd,
On 5/18/20 3:43 PM, Sjoerd Meijer wrote:
>...
2020 May 19
2
LV: predication
...rinsics.
Cheers,
Sjoerd.
________________________________
From: Simon Moll <Simon.Moll at EMEA.NEC.COM>
Sent: 19 May 2020 15:07
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <listmail at philipreames.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sander De Smalen <Sander.DeSmalen at arm.com>; hanna.kruppe at gmail.com <hanna.kruppe at gmail.com>
Subject: Re: [llvm-dev] LV: predication
On 5/19/20 12:38 PM, Sjoerd Meijer wrote:
Hi Simon,
Tha...
2014 Feb 24
2
[LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)
On 02/24/2014 11:27 AM, Andrew Trick wrote:
>
> On Feb 24, 2014, at 11:17 AM, Philip Reames <listmail at philipreames.com
> <mailto:listmail at philipreames.com>> wrote:
>
>>
>> On 02/24/2014 12:45 AM, Andrew Trick wrote:
>>>
>>> On Feb 21, 2014, at 10:37 AM, Philip Reames
>>> <listmail at philipreames.com <mailto:listmail at philipreames.com>>...
2020 May 18
2
LV: predication
...e this explicit.
Cheers.
________________________________
From: Simon Moll <Simon.Moll at EMEA.NEC.COM>
Sent: 18 May 2020 14:11
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <listmail at philipreames.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sander De Smalen <Sander.DeSmalen at arm.com>; hanna.kruppe at gmail.com <hanna.kruppe at gmail.com>
Subject: Re: [llvm-dev] LV: predication
On 5/18/20 2:53 PM, Sjoerd Meijer wrote:
Hi,
I abandoned...
2015 Jan 07
5
[LLVMdev] Is address space 1 reserved?
> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com> wrote:
>
>
> On 01/07/2015 11:52 AM, Matt Arsenault wrote:
>>
>>> On Jan 7, 2015, at 2:25 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote:
>>>
>>> I'm not aware of any such restriction, and I know of...
2020 Feb 05
3
IndVarSimplify: getBackedgeTakenCount and Release vs Assert
...vm.
The culprit is IndVarSimplify that comes up with different behavior on the same input:
in the assertion build, it does do an extra 'INDVARS: Rewriting loop exit condition'
After digging around, it seems that following change is the culprit:
-----
Author: Philip Reames <listmail at philipreames.com> 2019-08-01 03:16:08
Committer: Philip Reames <listmail at philipreames.com> 2019-08-01 03:16:08
Fix a release-only build warning triggered by rL367485
llvm-svn: 367499
[..]
+#ifndef NDEBUG
+ // Used below for a consistency check only
const SCEV *BackedgeTaken...
2020 Apr 17
2
Scalar Evolution Expressions Involving Sibling Loops
...et canceled out. Having said that it may still be a reasonable
middle-ground solution.
Philip, do you have any thoughts on that?
Bardia Mahjour
From: Jimmy Zhongduo Lin <jimmy.zhongduo.lin at huawei.com>
To: Bardia Mahjour <bmahjour at ca.ibm.com>
Cc: Philip Reames <listmail at philipreames.com>,
"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Date: 2020/04/16 08:39 PM
Subject: [EXTERNAL] RE: [llvm-dev] Scalar Evolution Expressions
Involving Sibling Loops
Hi Bardia,
This is actually a long known problem:
http://lists.llvm.org/...
2015 Jan 07
2
[LLVMdev] Is address space 1 reserved?
On 01/07/2015 12:17 PM, Pete Cooper wrote:
>
>> On Jan 7, 2015, at 12:05 PM, Matt Arsenault <arsenm2 at gmail.com
>> <mailto:arsenm2 at gmail.com>> wrote:
>>
>>
>>> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com
>>> <mailto:listmail at philipreames.com>> wrote:
>>>
>>>
>>> On 01/07/2015 11:52 AM, Matt Arsenault wrote:
>>>>
>>>>> On Jan 7, 2015, at 2:25 PM, Owen Anderson <resistor at mac.com
>>>>> <mailto:re...
2014 Feb 24
2
[LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)
On 02/24/2014 12:45 AM, Andrew Trick wrote:
>
> On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com
> <mailto:listmail at philipreames.com>> wrote:
>
>>
>> On 02/14/2014 05:55 PM, Philip Reames wrote:
>>> Splitting out a conversation which started in "make DataLayout a
>>> mandatory part of Module" since the topic has decidedly change...
2020 Apr 16
2
Scalar Evolution Expressions Involving Sibling Loops
...and make
alternative arrangements to avoid an assertion or miscompile.
Bardia Mahjour
Compiler Optimizations
IBM Toronto Software Lab
From: Jimmy Zhongduo Lin <jimmy.zhongduo.lin at huawei.com>
To: Bardia Mahjour <bmahjour at ca.ibm.com>, Philip Reames
<listmail at philipreames.com>, "llvm-dev at lists.llvm.org"
<llvm-dev at lists.llvm.org>
Date: 2020/04/16 04:34 PM
Subject: [EXTERNAL] RE: [llvm-dev] Scalar Evolution Expressions
Involving Sibling Loops
Hi Bardia,
I am encountering a similar problem and totally agree that ge...
2013 Oct 24
2
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On 10/23/13 5:38 PM, Andrew Trick wrote:
>
> On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com
> <mailto:listmail at philipreames.com>> wrote:
>
>>> The implementation of the two intrinsics is actually very similar.
>>> In this case, the difference would be that llvm.stackmap does not
>>> reserve space for patching, while llvm.patchpoint doe...
2015 Jan 07
2
[LLVMdev] Is address space 1 reserved?
> On Jan 7, 2015, at 3:10 PM, Philip Reames <listmail at philipreames.com> wrote:
>
>
> On 01/07/2015 12:05 PM, Matt Arsenault wrote:
>>
>>> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>>>
>>>
>>> On 01/07/2015 11:52 AM, M...
2013 Oct 24
1
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On 10/23/13 10:03 PM, Andrew Trick wrote:
>
> On Oct 23, 2013, at 7:26 PM, Philip Reames <listmail at philipreames.com
> <mailto:listmail at philipreames.com>> wrote:
>
>> On 10/23/13 5:38 PM, Andrew Trick wrote:
>>>
>>> On Oct 23, 2013, at 5:27 PM, Philip Reames
>>> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>&g...
2020 May 18
2
LV: predication
...implements this.
Cheers.
________________________________
From: Simon Moll <Simon.Moll at EMEA.NEC.COM>
Sent: 18 May 2020 13:32
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <listmail at philipreames.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sander De Smalen <Sander.DeSmalen at arm.com>; hanna.kruppe at gmail.com <hanna.kruppe at gmail.com>
Subject: Re: [llvm-dev] LV: predication
On 5/5/20 12:07 AM, Sjoerd Meijer via llvm-dev wrote:
wh...
2016 Mar 30
4
JIT compiler and calls to existing functions
...tive.
>
> Is there any example code or documentation you can point to for details
> about how to implement the symbolic approach? Is it similar to any of the
> versions of Kaleidoscope or any other extant tutorial?
>
> On Tue, Mar 29, 2016 at 5:07 AM, Philip Reames <listmail at philipreames.com>
> wrote:
>
>> Other advantages of keeping things symbolic:
>> 1) You can use function attributes to provide optimization or semantic
>> information.
>> 2) Linking modules works as expected when one of them contains the
>> definition.
>> 3) You can...
2015 Jul 31
4
[LLVMdev] Clang devirtualization proposal
On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com>
wrote:
>
> Quoting from the google doc: "If we don’t know definition of some
> function, we assume that it will not call @llvm.invariant.group.barrier().
> "
> This part really really bugs me. We generally try to assume minimal
> knowledge of external function...
2016 Mar 29
3
JIT compiler and calls to existing functions
...nt advantage from my perspective.
Is there any example code or documentation you can point to for details
about how to implement the symbolic approach? Is it similar to any of the
versions of Kaleidoscope or any other extant tutorial?
On Tue, Mar 29, 2016 at 5:07 AM, Philip Reames <listmail at philipreames.com>
wrote:
> Other advantages of keeping things symbolic:
> 1) You can use function attributes to provide optimization or semantic
> information.
> 2) Linking modules works as expected when one of them contains the
> definition.
> 3) You can get better code generation (i.e....