On 10/16/12 20:33, Ian Lance Taylor wrote:
On Tue, Oct 16, 2012 at 4:54 PM, Aldy Hernandez wrote:
On 10/16/12 13:28, Jakub Jelinek wrote:
location of considered if-conversion on mem
if (some_condition)
call ();
mem = something;
Are we not currently being conservative in
On 10/16/12 23:21, Jeff Law wrote:
On 10/16/2012 07:51 PM, Richard Henderson wrote:
On 2012-10-17 09:53, Aldy Hernandez wrote:
+/* Like memory_modified_in_insn_p, but return TRUE if INSN will
+ *SURELY* modify the memory contents of MEM. */
+bool
+memory_surely_modified_in_insn_p (const_rtx
On 10/16/2012 07:51 PM, Richard Henderson wrote:
On 2012-10-17 09:53, Aldy Hernandez wrote:
+/* Like memory_modified_in_insn_p, but return TRUE if INSN will
+ *SURELY* modify the memory contents of MEM. */
+bool
+memory_surely_modified_in_insn_p (const_rtx mem, const_rtx insn)
I don't like
On 2012-10-17 09:53, Aldy Hernandez wrote:
> +/* Like memory_modified_in_insn_p, but return TRUE if INSN will
> + *SURELY* modify the memory contents of MEM. */
> +bool
> +memory_surely_modified_in_insn_p (const_rtx mem, const_rtx insn)
I don't like the word "surely". Are we certain or not?
I
On Tue, Oct 16, 2012 at 4:54 PM, Aldy Hernandez wrote:
> On 10/16/12 13:28, Jakub Jelinek wrote:
>
>> I see another problem with noce_can_store_speculate_p, the return false;
>> checks. The search for a store to exactly that location can be done
>> just on post dominator bbs, but I wonder how you
On Tue, Oct 16, 2012 at 4:53 PM, Aldy Hernandez wrote:
>
>> Clearly we could consider the possibility of a PARALLEL of SET insns,
>> but of course most the compiler won't handle that anyhow. I suppose
>> that would be a reason to use memory_surely_modified_in_insn_p, but in
>> that case you might
On 10/16/12 13:28, Jakub Jelinek wrote:
I see another problem with noce_can_store_speculate_p, the return false;
checks. The search for a store to exactly that location can be done
just on post dominator bbs, but I wonder how you can avoid looking for
volatile insns or non-const/pure calls (or
I don't see a reason to add this new function. I would just inline it
into noce_can_store_speculate_p, replacing the call to
memory_modified_in_p. And I'm not sure I see a reason to change the
comment for memory_modified_in_p, it seems to already be accurate.
My comment was just clearer to m
On Tue, Oct 16, 2012 at 10:19:54AM -0700, Ian Lance Taylor wrote:
> On Mon, Oct 15, 2012 at 5:28 AM, Aldy Hernandez wrote:
> I don't see a reason to add this new function. I would just inline it
> into noce_can_store_speculate_p, replacing the call to
> memory_modified_in_p. And I'm not sure I s
On Mon, Oct 15, 2012 at 5:28 AM, Aldy Hernandez wrote:
>
> Here we have a store data race because noce_can_store_speculate_p()
> incorrectly returns true. The problem is that memory_modified_in_insn_p()
> returns true if an instruction *MAY* modify a memory location, but the store
> can only be s
On 10/15/2012 08:28 AM, Aldy Hernandez wrote:
I am having a bit of a problem coming up with a generic testcase.
Perhaps Andrew or others have an idea.
The attached testcase fails to trigger without the patch, because
AFAICT we have no way of testing an addition of zero to a memory
location:
[Ian, I am copying you because this is originally your code. Richard, I
am copying you because you are all things aliased :-). And Andrew is
here because I am unable to come up with a suitable test for the
simulate-thread harness.].
Here we have a store data race because noce_can_store_specu
12 matches
Mail list logo
