Displaying 20 results from an estimated 7000 matches similar to: "Constants propagation into printf format string"
2018 May 17
0
Constants propagation into printf format string
On Thu, May 17, 2018 at 3:53 PM, Dávid Bolvanský via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I was thinking about a new possible simplification in InstCombine which
> would transform code like this:
>
> const char * NAME = "Prog";
>
> void printer(char **arr, int len) {
> for (int i = 0; i < len; ++i) {
> printf("%s:
2018 May 18
1
Constants propagation into printf format string
On 5/17/2018 4:04 PM, Davide Italiano via llvm-dev wrote:
> On Thu, May 17, 2018 at 3:53 PM, Dávid Bolvanský via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hello,
>>
>> I was thinking about a new possible simplification in InstCombine which
>> would transform code like this:
>>
>> const char * NAME = "Prog";
>>
>> void
2018 Apr 20
2
Missed strlen optimizations
Use *last = nullptr;
for (Use &U : Src->uses())
last = &U;
last->getUser()->dump();
Or any better solution?
2018-04-20 19:19 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
> Is:
>
>
> 2018-04-20 18:07 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
>
>> Hello,
>>
>> Code: https://godbolt.org/g/EG4Wi6
2018 May 22
2
DSE: Remove useless stores between malloc & memset
You might want to look more carefully at how you're constructing the
MemoryLocation. The first argument is a pointer, and the second
argument is the number of bytes pointed to by that pointer (or
MemoryLocation::UnknownSize if the number of bytes accessed isn't known).
More generally, copy-pasting code you don't understand isn't a good idea.
-Eli
On 5/22/2018 4:02 PM, Dávid
2018 May 22
2
DSE: Remove useless stores between malloc & memset
It works with
MemoryLocation MemoryLocation::get(const CallInst *CI) {
AAMDNodes AATags;
CI->getAAMetadata(AATags);
const auto &DL = CI->getModule()->getDataLayout();
return MemoryLocation(CI, DL.getTypeStoreSize(CI->getType()), AATags);
}
Is it fine? :)
2018-05-22 23:56 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
> Looks like there are many overloads
2018 Apr 20
0
Missed strlen optimizations
Maybe nicer..
auto i = Src->uses().begin();
std::advance(i, Src->getNumUses() - 1);
i->getUser()->dump();
2018-04-20 19:19 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
> Use *last = nullptr;
> for (Use &U : Src->uses())
> last = &U;
> last->getUser()->dump();
>
>
> Or any better solution?
>
> 2018-04-20 19:19
2018 May 22
2
DSE: Remove useless stores between malloc & memset
Full stack trace:
opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T*
llvm::Optional<T>::getPointer() [with T = llvm::MemoryLocation]: Assertion
`Storage.hasVal' failed.
Stack dump:
0. Program arguments: opt aaa.ll -dse -S
1. Running pass 'Function Pass Manager' on module 'aaa.ll'.
2. Running pass 'Dead Store Elimination' on function
2018 May 09
3
Ignored branch predictor hints
Hello,
#define likely(x) __builtin_expect((x),1)
// switch like
char * b(int e) {
if (likely(e == 0))
return "0";
else if (e == 1)
return "1";
else return "f";
}
GCC correctly prefers the first case:
b(int):
mov eax, OFFSET FLAT:.LC0
test edi, edi
jne .L7
ret
But Clang seems to ignore _builtin_expect hints in this case.
2018 May 22
0
DSE: Remove useless stores between malloc & memset
Yeah, sorry for that. Better "It compiles ok (but maybe incorrect code)",
not "It works" as I wrote.
2018-05-23 1:08 GMT+02:00 Friedman, Eli <efriedma at codeaurora.org>:
> You might want to look more carefully at how you're constructing the
> MemoryLocation. The first argument is a pointer, and the second argument
> is the number of bytes pointed to by
2018 May 09
2
Ignored branch predictor hints
Hi Dávid,
Looks like you can defeat the switch conversion by adding a dummy asm(“”):
#define likely(x) __builtin_expect((x),1)
// switch like
char * b(int e) {
if (likely(e == 0))
return "0";
asm("");
if (e == 1)
return "1";
else return "f";
}
Dave
> On May 9, 2018, at 2:33 PM, Dávid Bolvanský via llvm-dev
2018 May 22
0
DSE: Remove useless stores between malloc & memset
IR:
define i32 @calloc_strlen_write_between() {
%call = tail call noalias i8* @calloc(i32 10, i32 1)
store i8 97, i8* %call, align 1
%call1 = tail call i32 @strlen(i8* %call)
ret i32 %call1
}
static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI,
AliasAnalysis *AA, MemoryDependenceResults *MD,
const DataLayout &DL, const TargetLibraryInfo *TLI,
2018 May 22
2
DSE: Remove useless stores between malloc & memset
* if (isStringFromCalloc(Dst, TLI)) should be if (!isStringFromCalloc(Dst,
TLI))
but still asserting...
2018-05-22 23:06 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
> Can you help a bit?
>
> I try to work with DSE but I got the following assert:
> opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T*
> llvm::Optional<T>::getPointer() [with T
2018 May 22
4
Rewriting calls to varargs functions
It could save useless parsing in s/f/printf during runtime.
E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I
think it could be quite useful.
After this transformation we would get fprintf(f, "ABC: %s", msg); --> We
could save one push/mov instruction + less parsing in printf every time we
call it. We would just replace string constant
2018 May 22
0
DSE: Remove useless stores between malloc & memset
Looks like there are many overloads for "get".
http://llvm.org/doxygen/MemoryLocation_8cpp_source.html
But nothing for CallInst. Any suggestions how to do a proper one? I will
look at it too.
2018-05-22 23:34 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
> Full stack trace:
>
> opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T*
>
2018 May 09
0
Ignored branch predictor hints
I did
https://bugs.llvm.org/show_bug.cgi?id=37368
2018-05-09 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>:
> I did
>
> https://bugs.llvm.org/show_bug.cgi?id=37368
>
> 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io>:
>
>> I’d wager that the if-else chain is being converted to a "switch
>> statement” during an optimization
2018 May 21
2
DSE: Remove useless stores between malloc & memset
memoryIsNotModifiedBetween is precisely the sort of expensive walk we
shouldn't be doing... I'm surprised it hasn't caused any serious issues
yet. Ideally, what we should be doing is using MemorySSA to find a
dependency from the memset: if the closest dependency is the malloc,
there aren't any stores between the memset and the malloc. (But we
aren't using MemorySSA in
2018 May 17
3
DSE: Remove useless stores between malloc & memset
Hello,
I would like to find a way to do this removal properly. I found DSE and
"eliminateNoopStore" can be useful for this thing.
What I mean?
int *test = malloc(15 * sizeof(int));
test[10] = 12; < ----- remove this store
memset(test,0,sizeof(int) * 15);
I already checked the function "eliminateNoopStore".
Looks good, I think I would be to get the value ("A") we
2018 Apr 20
2
Missed strlen optimizations
Hello,
Code: https://godbolt.org/g/EG4Wi6
unsigned fff3(void) {
char buf[10] = "";
return strlen(buf);
}
Since we are memset-ing before strlen call, we could replace strlen with
just 0.
Has LLVM any API to get "last instruction before strlen" which modifies
strlen argument "buf"? So we can check "yes, it is memset there, replace
strlen with zero"
2018 Sep 15
2
New warnings when building trunk with GCC 9
There is a new discussion related to -Wredundant-move warning on GCC
bugzilla.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300
pi 14. 9. 2018 o 9:53 David Blaikie <dblaikie at gmail.com> napísal(a):
>
>
> On Fri, Sep 14, 2018 at 12:48 AM Stephan Bergmann <sbergman at redhat.com>
> wrote:
>
>> On 13/09/2018 18:22, David Blaikie via llvm-dev wrote:
>>
2018 May 22
0
DSE: Remove useless stores between malloc & memset
It looks like the memoryIsNotModifiedBetween assumes the second argument
is a store, or some other instruction supported by MemoryLocation::get.
If you're passing in something else, you'll have to compute the
MemoryLocation some other way.
(Generally, if you're asking a question about an assertion, please
include the whole stack trace; it's hard to guess what's happening