LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 1362 - alignment on malloc instruction is not codegened correctly
Summary: alignment on malloc instruction is not codegened correctly
Status: RESOLVED DUPLICATE of bug 715
Alias: None
Product: libraries
Classification: Unclassified
Component: Common Code Generator Code (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
: 1531 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-26 14:28 PDT by Andrew Lenharth
Modified: 2009-03-17 13:41 PDT (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
align test (943 bytes, text/plain)
2007-04-26 14:37 PDT, Andrew Lenharth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Lenharth 2007-04-26 14:28:16 PDT
the backends (including C and x86) do not respect alignment on malloc.  consider
test/Features/alignment.ll.  The final malloc (%T) should be codegened to a
memalign to preserve the alignment.

Once this is done, all memalign and posix_memalign calls can be safely
transformed into llvm malloc instructions.  Plus it is just broken right now.
Comment 1 Andrew Lenharth 2007-04-26 14:37:10 PDT
Created attachment 809 [details]
align test
Comment 2 Andrew Lenharth 2007-04-26 14:38:46 PDT
This test (align.ll) should output all 0s if the align is being respected.  It
is derived from:

#include <stdlib.h>
#include <stdio.h>
#include <malloc.h>

int main(int argc, char** argv) {
  int x;
  char* p;
  for (x = 0; x < 100; ++x) {
    p = memalign(256, 1);
    printf("%d", (int)p & 0x00FF);
  }
}

changing the memalign call into a malloc 1, align 256, which should have the
same semantics according to the language reference.
Comment 3 Chris Lattner 2007-04-26 14:59:46 PDT
true.  The problem is that not all targets support memalign, e.g. darwin.
Comment 4 Chris Lattner 2007-07-02 12:47:56 PDT
*** Bug 1531 has been marked as a duplicate of this bug. ***
Comment 5 Mathias Gaunard 2007-07-02 17:22:01 PDT
There are a few ways to fix the issue:

 - write a memory allocator, eventually on top of malloc, that can provide
memory for any alignment, and use it instead of posix_memalign when it is not
available (or always use it if it's better).

 - just allocate more than necessary, increment the pointer before returning it,
and write implementation-specific info in that padding memory so that the
incremented pointer can still work with free. An alternative would be to somehow
write how much it needs to be decremented before calling free. No such trick
would be necessary if the free instruction took an align argument which value
was the same as the corresponding malloc, but it may be non-trivial or
impossible to find out with C code.
Comment 6 Chris Lattner 2007-07-02 18:02:45 PDT
> - write a memory allocator, eventually on top of malloc
> - just allocate more than necessary.

Neither of these are abi compatible with GCC.  this would prevent you from compiling one .c file with llvm 
and one .c file with GCC and linking them together.  Why not just call posix_memalign if that is what you 
want?

-Chris

Comment 7 Mathias Gaunard 2007-07-02 18:15:00 PDT
Because posix_memalign is not available on all platforms.
Comment 8 Chris Lattner 2009-03-17 13:36:45 PDT
The real fix for this is to just remove the mallocinst instruction.
Comment 9 Chris Lattner 2009-03-17 13:41:07 PDT

*** This bug has been marked as a duplicate of bug 715 ***