[llvm-dev] Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?

[Than McIntosh via llvm-dev]

The rationale given does not seem to square (IMHO) with the ubiquitous
practice of having 0- or 1-length array at the end of a struct and then
allocating additional elements for it using malloc, or the so-called
"struct hack":

 http://c-faq.com/struct/structhack.html

For example:

  typedef struct {
    enum inst_type type;
    unsigned num_ops;
    struct operand ops[1];
  } inst;

  // allocate an instruction with specified number of operands
  int *allocate_inst(unsigned num_operands) {
    char *mem = malloc(sizeof(inst) + sizeof(struct operand) *
(num_operands-1));
    return (inst *) mem;
  }

Or maybe the reasoning is that computing a pointer off the beginning of
something (e.g. &c - X) is somehow worse than computing a pointer off the
end of something (e.g. &c + X)?

Than


On Tue, Mar 22, 2016 at 11:41 AM, Chuang-Yu Cheng via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Reply from Michael:
>
> &x points to the start of object x, and &x - something (something != 0)
> points outside object x.  'c' was a complete object, so &c-8 points
> outside any object, hence the formation of that pointer is already
> invalid (as is its dereference).
>
> https://gcc.gnu.org/ml/gcc/2016-03/msg00185.html
>
> >>On Fri, Mar 18, 2016 at 8:46 AM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >>
> >>    I *think the argument* goes that this is a 20 or 24 byte object, so
> if you *could* put something of type PB at c-8, you'd illegally overlap
> with the object at c.
> >>
> >>    Thus, there can't be an object of type PB at c-8.
> >>
> >>    (IE any valid object must be sizeof(PB) away in either direction,
> which means it's not possible for c->f1_ to clobber c no matter what bar
> does)
>
> >>> We discussed this issue briefly on the #gcc IRC channel.
> >>> Richard Biener pointed out that bar cannot make c point to &c - 8,
> >>> because computing that pointer would be invalid. So c->f1_ cannot
> >>> clobber c itself.
> >>>
> >>> --
> >>> Markus
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/4d066fb7/attachment.html>