joerg added a comment.
There are two different considerations here:
(1) Create less target code
(2) Create less IR
If this code can significantly reduce the amount of IR, it can be useful in
general. That's why the existing memset logic is helpful.
Repository:
rL LLVM
https://reviews.llvm.o
jfb added a comment.
In https://reviews.llvm.org/D49771#1183641, @mehdi_amini wrote:
> > I'm worried, however, about generating a bunch more code than needed from
> > clang in the hopes that the compiler will clean it up later.
>
> Isn't a strong design component of clang/LLVM? Clang does not tr
mehdi_amini added a comment.
> I'm worried, however, about generating a bunch more code than needed from
> clang in the hopes that the compiler will clean it up later.
Isn't a strong design component of clang/LLVM? Clang does not try to generate
"smart" code and leave it up to LLVM to clean it
jfb added a comment.
In https://reviews.llvm.org/D49771#1183562, @mehdi_amini wrote:
> In https://reviews.llvm.org/D49771#1183380, @jfb wrote:
>
> > In https://reviews.llvm.org/D49771#1181008, @mehdi_amini wrote:
> >
> > > I'm curious: isn't the kind of optimization we should expect LLVM to
> >
mehdi_amini added a comment.
In https://reviews.llvm.org/D49771#1183380, @jfb wrote:
> In https://reviews.llvm.org/D49771#1181008, @mehdi_amini wrote:
>
> > I'm curious: isn't the kind of optimization we should expect LLVM to
> > provide?
>
>
> Maybe? It seems obvious to do here since we know we
jfb added a comment.
In https://reviews.llvm.org/D49771#1181008, @mehdi_amini wrote:
> I'm curious: isn't the kind of optimization we should expect LLVM to provide?
Maybe? It seems obvious to do here since we know we'll probably want to be
doing it, and I have another patch I'm working on whic
mehdi_amini added a comment.
I'm curious: isn't the kind of optimization we should expect LLVM to provide?
Repository:
rL LLVM
https://reviews.llvm.org/D49771
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/m
This revision was automatically updated to reflect the committed changes.
Closed by commit rL337887: CodeGen: use non-zero memset when possible for
automatic variables (authored by jfb, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D49771
jfb marked an inline comment as done.
jfb added a comment.
Addressed all comments.
Comment at: lib/CodeGen/CGDecl.cpp:956-957
+class BytePattern {
+ uint8_t Val;
+ enum class ValueType { Specific, Any, None } Type;
+ BytePattern(ValueType Type) : Type(Type) {}
--
jfb updated this revision to Diff 157191.
jfb marked 2 inline comments as done.
jfb added a comment.
- Use short to test padding between array elements.
- Define enum class storage type; swap order of if / else to make it more
readable.
Repository:
rC Clang
https://reviews.llvm.org/D49771
F
bogner accepted this revision.
bogner added a comment.
This revision is now accepted and ready to land.
Seems straightforward and correct to me.
Comment at: lib/CodeGen/CGDecl.cpp:956-957
+class BytePattern {
+ uint8_t Val;
+ enum class ValueType { Specific, Any, None } Type;
Quuxplusone added inline comments.
Comment at: test/CodeGen/init.c:202
+ union U { char c; int i; };
+ struct S { union U u; int i; };
+ struct S arr[5] = { { {0xF0}, 0xF0F0F0F0 }, { {0xF0}, 0xF0F0F0F0 }, {
{0xF0}, 0xF0F0F0F0 }, { {0xF0}, 0xF0F0F0F0 }, { {0xF0}, 0xF0F0F0F0 },
jfb created this revision.
jfb added a reviewer: dexonsmith.
Herald added a subscriber: cfe-commits.
Right now automatic variables are either initialized with bzero followed by a
few stores, or memcpy'd from a synthesized global. We end up encountering a
fair amount of code where memcpy of non-z
13 matches
Mail list logo
