Displaying 20 results from an estimated 50000 matches similar to: "[LLVMdev] optimization assumes malloc return is non-null"
2008 Apr 30
0
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 2:10 PM, Ryan M. Lefever wrote:
> Consider the following c code:
>
> #include <stdlib.h>
>
> int main(int argc, char** argv){
> if(malloc(sizeof(int)) == NULL){ return 0; }
> else{ return 1; }
> }
>
>
> When I compile it with -O3, it produces the following bytecode:
>
> define i32 @main(i32 %argc, i8** %argv) {
> entry:
>
2008 Apr 30
2
[LLVMdev] optimization assumes malloc return is non-null
Daveed:
Perhaps I am looking at the wrong version of the specification. Section
5.1.2.3 appears to refer to objects having volatile-qualified type. The
type of malloc() is not volatile qualified in the standard library
definition.
In general, calls to procedures that are outside the current unit of
compilation are presumed to involve side effects performed in the body
of the external procedure
2008 Apr 30
0
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 2:47 PM, Jonathan S. Shapiro wrote:
> Daveed:
>
> Perhaps I am looking at the wrong version of the specification.
> Section
> 5.1.2.3 appears to refer to objects having volatile-qualified type.
> The
> type of malloc() is not volatile qualified in the standard library
> definition.
More importantly, malloc() is not specified to access a volatile
2008 Apr 30
5
[LLVMdev] optimization assumes malloc return is non-null
On Wed, 2008-04-30 at 15:25 -0400, David Vandevoorde wrote:
> On Apr 30, 2008, at 2:47 PM, Jonathan S. Shapiro wrote:
> > Daveed:
> >
> > Perhaps I am looking at the wrong version of the specification.
> > Section
> > 5.1.2.3 appears to refer to objects having volatile-qualified type.
> > The
> > type of malloc() is not volatile qualified in the
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote:
> On Wednesday 30 April 2008 21:21, Chris Lattner wrote:
>
> > If LLVM is able to eliminate all users of the malloc assuming the
> > malloc succeeded (as in this case), then it is safe to assume the malloc
> > returned success.
>
> Ah, I missed this bit. I didn't see that the result of malloc was not used
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
On Wednesday 30 April 2008 21:21, Chris Lattner wrote:
> If LLVM is able to eliminate all users of the malloc assuming the
> malloc succeeded (as in this case), then it is safe to assume the malloc
> returned success.
Ah, I missed this bit. I didn't see that the result of malloc was not used
outside the if test.
But is the if test considered a "use?" If so, it's a
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Wed, 30 Apr 2008, Ryan M. Lefever wrote:
> Consider the following c code:
> #include <stdlib.h>
> int main(int argc, char** argv){
> if(malloc(sizeof(int)) == NULL){ return 0; }
> else{ return 1; }
> }
>
>
> When I compile it with -O3, it produces the following bytecode:
>
> define i32 @main(i32 %argc, i8** %argv) {
> entry:
> ret i32 1
2008 Apr 30
6
[LLVMdev] optimization assumes malloc return is non-null
On Wednesday 30 April 2008 17:26, David Vandevoorde wrote:
> >> ...malloc() is not specified to access a volatile
> >> object, modify an object, or modifying a file (directly or
> >> indirectly); i.e., it has no side effect from the language point of
> >> view.
> >
> > Daveed:
> >
> > Good to know that I was looking at the correct
2008 Jun 23
2
[LLVMdev] optimization assumes malloc return is non-null
On Thursday 01 May 2008 19:14, Jonathan S. Shapiro wrote:
> On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote:
> > On Wednesday 30 April 2008 21:21, Chris Lattner wrote:
> >
> > > If LLVM is able to eliminate all users of the malloc assuming the
> > > malloc succeeded (as in this case), then it is safe to assume the malloc
> > > returned success.
>
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Wed, 2008-04-30 at 18:17 -0500, David A. Greene wrote:
> On Wednesday 30 April 2008 17:26, David Vandevoorde wrote:
>
> > >> ...malloc() is not specified to access a volatile
> > >> object, modify an object, or modifying a file (directly or
> > >> indirectly); i.e., it has no side effect from the language point of
> > >> view.
> >
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
On May 1, 2008, at 12:47 PM, David Greene wrote:
> On Wednesday 30 April 2008 20:01, David Vandevoorde wrote:
>
>> Correct. It's an extreme form of garbage collection, I suppose ;-)
>>
>> (In theory, it can also be assumed to fail -- because an
>> implementation is allowed to make any call to malloc fail -- though
>> that's probably not useful.)
>
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
Sorry, for j
On Thu, May 1, 2008 at 1:16 PM, David Vandevoorde
<daveed at vandevoorde.com> wrote:
>
> Another valid implementation of malloc is one that actually returns a
> non-null pointer in this case, and for such an implementation, a valid
> reduction is "int main() { return 1; }". That reduction is IMO not
> only valid, but also defensible and maybe
2008 Apr 30
0
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 5:20 PM, Jonathan S. Shapiro wrote:
> On Wed, 2008-04-30 at 15:25 -0400, David Vandevoorde wrote:
>> On Apr 30, 2008, at 2:47 PM, Jonathan S. Shapiro wrote:
>>> Daveed:
>>>
>>> Perhaps I am looking at the wrong version of the specification.
>>> Section
>>> 5.1.2.3 appears to refer to objects having volatile-qualified type.
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 8:47 PM, Jonathan S. Shapiro wrote:
> On Wed, 2008-04-30 at 18:17 -0500, David A. Greene wrote:
>> On Wednesday 30 April 2008 17:26, David Vandevoorde wrote:
>>
>>>>> ...malloc() is not specified to access a volatile
>>>>> object, modify an object, or modifying a file (directly or
>>>>> indirectly); i.e., it has no
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 7:17 PM, David A. Greene wrote:
> On Wednesday 30 April 2008 17:26, David Vandevoorde wrote:
>
>>>> ...malloc() is not specified to access a volatile
>>>> object, modify an object, or modifying a file (directly or
>>>> indirectly); i.e., it has no side effect from the language point of
>>>> view.
>>>
>>>
2008 May 01
2
[LLVMdev] optimization assumes malloc return is non-null
On Wed, 2008-04-30 at 18:26 -0400, David Vandevoorde wrote:
> > Daveed:
> >
> > Good to know that I was looking at the correct section. I do not agree
> > that your interpretation follows the as-if rule, because I do not
> > agree
> > with your interpretation of the C library specification of malloc().
>
>
> Before I go on, let me state that this is
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Wednesday 30 April 2008 20:01, David Vandevoorde wrote:
> Correct. It's an extreme form of garbage collection, I suppose ;-)
>
> (In theory, it can also be assumed to fail -- because an
> implementation is allowed to make any call to malloc fail -- though
> that's probably not useful.)
You just contradicted yourself. If an implementation can return zero/null,
then the
2007 Mar 06
6
[LLVMdev] alloca & store generation
I am writing a transformation that needs to add a call to a function F()
at the beginning of main() with the addresses of argc and argv as
parameters to F(). However, the bytecode file I'm transforming has not
allocated space on the stack for argc and argv. So, I developed my
transformation to change main() from:
-----
int main(int %argc, sbyte** %argv){
entry:
...
// some use of
2008 May 01
2
[LLVMdev] optimization assumes malloc return is non-null
On Wed, 30 Apr 2008, David Vandevoorde wrote:
> Note that more interesting optimizations are possible. E.g., it's
> perfectly valid to transform:
>
> void f(size_t n) {
> char *str = (char*)malloc(n);
> // use str[0 .. 99 ]
> free(str);
> }
>
> into
>
> void f(size_t n) {
> char *str = (char*)alloca(n);
> // use str[0 .. 99 ]
> }
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 9:35 PM, Jonathan S. Shapiro wrote:
> On Wed, 2008-04-30 at 18:26 -0400, David Vandevoorde wrote:
>>> Daveed:
>>>
>>> Good to know that I was looking at the correct section. I do not
>>> agree
>>> that your interpretation follows the as-if rule, because I do not
>>> agree
>>> with your interpretation of the C