On Fri, Jan 18, 2008 at 05:45:49PM +0100, ecolbus@voila.fr wrote:
quoted text
> The malloc attribute is exactly about this : giving the compiler the
> indication that no other pointer aliases this object, allowing for
> better optimizations.

If you put a malloc attribute on the allocator and no free attribute
on the deallocator, you can get bugs indeed.  GIGO.


quoted text
> Yes. Bad things start to happen when users add wrong indications to
> the compiler. By adding the "const" indication to kfree(), the programmer
> wrongly tells that it can optimize reading the values pointed to before or
> after calling the function (if it is also sure that they cannot be
> read/written otherwise). Current gcc implementations seem quite
> conservative in this regard, and don't optimize that much, but what about
> the future?

The future should be quite nice because:

- the compiler can not know that kmalloc does not have an alias to
  the pointer tucked somewhere accessible by other non-inline functions
  (as kfree is), especially since it does have aliases in practice, so
  it cannot prove to "not read/written otherwise" part without the
  malloc attribute

- if you add the (non-standard C) malloc attribute to kmalloc, then
  you also add the free attribute to kfree which tells the compiler
  that the pointer is invalid after the call, which ensures no
  accesses will be moved after it

  OG.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/