Displaying 8 results from an estimated 8 matches for "undefinednesses".
Did you mean:
undefinedness
2009 Jun 10
0
[LLVMdev] Call to address 0 gets removed
There's another point that hasn't been raised yet here, which is that
the
undefinedness of calling (void*) 0 is a property of C, not necessarily
of
the LLVM abstract language. I think you can make an excellent case that
the standard optimizations should not be enforcing C language semantics,
or at least should allow such optimizations to be disabled.
Case in point —
2009 Jun 10
3
[LLVMdev] Call to address 0 gets removed
> Dale Johannesen wrote:
>> Paul Schlie wrote:
>>> Dale Johannesen wrote:
>>>> Marius Wachtler wrote:
>>>> ...
>>>> The call to address 0 gets removed.
>>>>
>>>> define i32 @t(i32 %a) noreturn nounwind readnone {
>>>> entry:
>>>> unreachable
>>>> }
>>>>
2010 Jan 26
2
[LLVMdev] some llvm/clang missed optimizations
A few random observations:
1.
Clang could do better with large but boring switches like this:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/E8/E88C5111.shtml
Performance of clang's output will be fine but this is a major code size
lose.
2.
Destruction of stupid loops is incomplete, sometimes due to phase
ordering problems:
2009 Jun 10
2
[LLVMdev] Call to address 0 gets removed
2009/6/10 John McCall <rjmccall at apple.com>
> There's another point that hasn't been raised yet here, which is that
> the
> undefinedness of calling (void*) 0 is a property of C, not necessarily
> of
> the LLVM abstract language. I think you can make an excellent case that
> the standard optimizations should not be enforcing C language semantics,
> or at
2010 Jan 26
0
[LLVMdev] some llvm/clang missed optimizations
On Tue, Jan 26, 2010 at 12:36 PM, John Regehr <regehr at cs.utah.edu> wrote:
> 2.
> Sometimes not:
>
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/EC/ECC74C0C.shtml
The primary issue here is that scalar evolution doesn't know how to
deal with loops using "sle" for the exit condition. Shouldn't be too
hard to fix now that we have overflow flags
2009 Jun 10
0
[LLVMdev] Call to address 0 gets removed
On Jun 10, 2009, at 1:18 PM, Nick Lewycky wrote:
> 2009/6/10 John McCall <rjmccall at apple.com>
> There's another point that hasn't been raised yet here, which is that
> the
> undefinedness of calling (void*) 0 is a property of C, not necessarily
> of
> the LLVM abstract language. I think you can make an excellent case
> that
> the standard optimizations
2016 Feb 29
0
[isocpp-parallel] Proposal for new memory_order_consume definition
...ortant performance implications in practice. Not for
the kernel of course. Now we can endlessly debate how (non)practical it
is to write HPC code in C or C++, but there we are.
> The fact is, undefined compiler behavior is never a good idea. Not for
> serious projects.
Perhaps if these undefinednesses wouldn't have been put into the standard,
people wouldn't have written HPC code, and if that were so the world would
be a nicer place sometimes (certainly for the compiler). Alas, it isn't.
Ciao,
Michael.
2016 Feb 28
7
[isocpp-parallel] Proposal for new memory_order_consume definition
On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf
<markus at trippelsdorf.de> wrote:
>> >
>> > -fno-strict-overflow
>>
>> -fno-strict-aliasing.
>
> Do not forget -fno-delete-null-pointer-checks.
>
> So the kernel obviously is already using its own C dialect, that is
> pretty far from standard C.
> All these options also have a negative