Duncan Sands
2007-Nov-23 15:18 UTC
[LLVMdev] Getting rid of the DoesntAccessMemoryFns and OnlyReadsMemoryFns tables
The DoesntAccessMemoryFns and OnlyReadsMemoryFns tables are used by alias analysis to specify which standard functions don't access memory or only read memory. However gcc now automatically supplies this information to us. I checked on my x86 linux box what gcc gives for the functions listed in those tables. While gcc mostly agrees with them, there are the following differences (using -ffast-math, otherwise gcc says that a bunch of math ones are readonly because they depend on the floating point mode; I think gcc is correct to say this): function LLVM says gcc says -------- --------- -------- isalnum readnone readonly isalpha readnone readonly iscntrl readnone readonly isgraph readnone readonly islower readnone readonly isprint readnone readonly ispunct readnone readonly isspace readnone readonly isupper readnone readonly tolower readnone readonly toupper readnone readonly iswalnum readnone readonly iswalpha readnone readonly iswcntrl readnone readonly iswdigit readnone readonly iswgraph readnone readonly iswlower readnone readonly iswprint readnone readonly iswpunct readnone readonly iswspace readnone readonly iswupper readnone readonly iswxdigit readnone readonly towlower readnone readonly towupper readnone readonly iswctype readnone nothing towctrans readnone nothing btowc readnone nothing wctob readnone nothing nan readonly readnone nanf readonly readnone wcscoll readonly nothing feof readonly nothing ferror readonly nothing fileno readonly nothing feof_unlocked readonly nothing ferror_unlocked readonly nothing fileno_unlocked readonly nothing I think gcc marks all those alphabetical routines "readonly" rather than "readnone" because they depend on the locale; so I guess gcc is right about those ones. That leaves the following list for which gcc doesn't say either readnone or readonly on my machine: iswctype, towctrans, btowc, wctob, wcscoll, feof, ferror, fileno, feof_unlocked, ferror_unlocked, fileno_unlocked. We could keep some small tables just for these, or nuke the tables altogether and assume that gcc knows what it is doing. In my opinion we should believe gcc and nuke the tables. Ciao, Duncan.
Chris Lattner
2007-Nov-23 19:36 UTC
[LLVMdev] Getting rid of the DoesntAccessMemoryFns and OnlyReadsMemoryFns tables
On Fri, 23 Nov 2007, Duncan Sands wrote:> We could keep some small tables just for these, or nuke the tables altogether > and assume that gcc knows what it is doing. In my opinion we should believe > gcc and nuke the tables.Ding dong the tables are dead. Please remove them, thanks Duncan! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Wright
2007-Nov-24 14:13 UTC
[LLVMdev] Getting rid of the DoesntAccessMemoryFns and OnlyReadsMemoryFns tables
--- Duncan Sands <baldrick at free.fr> wrote:> The DoesntAccessMemoryFns and OnlyReadsMemoryFns tables are used > by alias analysis to specify which standard functions don't access > memory or only read memory. However gcc now automatically supplies > this information to us....> We could keep some small tables just for these, or nuke the tables altogether > and assume that gcc knows what it is doing. In my opinion we should believe > gcc and nuke the tables.I'm quite new to using LLVM, and thus don't have a complete understanding of how everything works yet, but won't removing this information have an impact on projects that use LLVM as a backend only, and thus don't get any gcc supplied information? Chris Wright ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Duncan Sands
2007-Nov-24 18:18 UTC
[LLVMdev] Getting rid of the DoesntAccessMemoryFns and OnlyReadsMemoryFns tables
Hi Chris,> I'm quite new to using LLVM, and thus don't have a complete understanding of > how everything works yet, but won't removing this information have an impact on > projects that use LLVM as a backend only, and thus don't get any gcc supplied > information?yes it will, but they can always add these tables to their code and use them to generate the appropriate readnone/readonly attributes. You should be aware that the tables were not that accurate. Ciao, Duncan.
Possibly Parallel Threads
- [LLVMdev] Getting rid of the DoesntAccessMemoryFns and OnlyReadsMemoryFns tables
- [LLVMdev] Getting rid of the DoesntAccessMemoryFns and OnlyReadsMemoryFns tables
- [klibc:master] stdio: Define all the _unlocked functions and macros
- Building R on RHEL 5
- [LLVMdev] "multiple definition of .. " in clang 2.8