Dávid Bolvanský via llvm-dev
2018-May-08 23:59 UTC
[llvm-dev] "Replace locked IO with unlocked IO" optimizations
Hello, Please check this patch: https://reviews.llvm.org/D45736 as Eli noted, other opinions are highly welcomed.. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180509/c2eb9888/attachment.html>
Friedman, Eli via llvm-dev
2018-May-09 00:13 UTC
[llvm-dev] "Replace locked IO with unlocked IO" optimizations
It's probably worth going into a little more detail... a lot of people read llvmdev, and most of them won't click the link or follow the whole discussion. The transform in question is replacing "fputc(...)" with "fputc_unlocked(...)" when we can prove the FILE* doesn't escape. The question is whether it's safe for the compiler to emit a call to fputc_unlocked() on Linux, given it's a non-standard extension. The bit I'm most worried about is some user defining a function named fputc_unlocked; it isn't a reserved name according to the C standard, so there's no way to ensure we're actually calling the glibc fputc_unlocked. Suggestions welcome. -Eli On 5/8/2018 4:59 PM, Dávid Bolvanský via llvm-dev wrote:> Hello, > > Please check this patch: > https://reviews.llvm.org/D45736 > > as Eli noted, other opinions are highly welcomed.. > > Thanks > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180508/bbec21ed/attachment.html>
Hal Finkel via llvm-dev
2018-May-09 00:23 UTC
[llvm-dev] "Replace locked IO with unlocked IO" optimizations
On 05/08/2018 07:13 PM, Friedman, Eli via llvm-dev wrote:> It's probably worth going into a little more detail... a lot of people > read llvmdev, and most of them won't click the link or follow the > whole discussion. > > The transform in question is replacing "fputc(...)" with > "fputc_unlocked(...)" when we can prove the FILE* doesn't escape. The > question is whether it's safe for the compiler to emit a call to > fputc_unlocked() on Linux, given it's a non-standard extension. The > bit I'm most worried about is some user defining a function named > fputc_unlocked; it isn't a reserved name according to the C standard, > so there's no way to ensure we're actually calling the glibc > fputc_unlocked.Don't we generally assume the availability of glibc extensions when -gnu is in the triple? -Hal> > Suggestions welcome. > > -Eli > > On 5/8/2018 4:59 PM, Dávid Bolvanský via llvm-dev wrote: >> Hello, >> >> Please check this patch: >> https://reviews.llvm.org/D45736 >> >> as Eli noted, other opinions are highly welcomed.. >> >> Thanks >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180508/a27513ed/attachment.html>