[llvm-dev] Aggregate load/stores

deadal nix via llvm-dev llvm-dev at lists.llvm.org
Sun Aug 16 19:05:53 PDT 2015


Hi all,

As most of you may now, LLVM is completely unable to do anything reasonable
with aggregate load/stores, beside just legalize them into something in the
backend.

This is not a good state of affair. Aggregate are part of LLVM IR, and as
such, LLVM should do something about them.

That is a bit of a chicken and egg issue: front end just implement their
own tricks to avoid aggregate or plain don't care about the resulting
executable as long as it works. As such, pretty much everybody that care
about this already implemented something in the front end.

Which is honestly rather stupid. Everybody is doing the same work again and
again because LLVM is not doing it.

That being said, I now know why LLVM is not doing it. Any attempt at making
things move on that front result in someone finding the solution not good
enough and stalling the process.

Things is, pretty much anything is better than nothing. Comparing any
current solution to an hypothetical nonexistant perfect solution is not
constructive. And at this stage, this is close to being disrespectful. I
have http://reviews.llvm.org/D9766 (from may) and no actionable item on it.
It was done as per feedback on previous discussion on the subject. There is
no proposal to improve the code, no proposal to do it another way, no
nothing. FROM MAY !

I'd like to get things moving here. If you guys don't give a s*** about it
because clang already have a work around, then fine. The good thing is that
it won't affect clang, for the very same reason: it is not using it. But
there are numerous front end out there, that do not have the manpower
backing clang, and all have to jump through hoops to handle aggregate for
LLVM not to mess up. So please be considerate for the smaller guys in town.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150816/34001796/attachment.html>


More information about the llvm-dev mailing list