Consider this snippet: typedef float v4sf __attribute__ ((vector_size (16))); float global; float waste_global (float p[4]) { __builtin_ia32_loadups (p); global += 1.0; } GCC now thinks __builtin_ia32_loadups clobbers global: waste_global (pD.1564) { floatD.28 D.1568; floatD.28 global.0D.1567; # BLOCK 0 # PRED: ENTRY [100.0%] (fallthru,exec) # globalD.1563_6 = V_MAY_DEF <globalD.1563_2>; __builtin_ia32_loadups (pD.1564_1); # VUSE <globalD.1563_6>; global.0D.1567_3 = globalD.1563; D.1568_4 = global.0D.1567_3 + 1.0e+0; # globalD.1563_5 = V_MUST_DEF <globalD.1563_6>; globalD.1563 = D.1568_4; return; # SUCC: EXIT [100.0%] } This is a bit silly, if we encourage people to use builtins instead of inline assembly.
Confirmed, I cannot remember or not if the rs6000/altivec builtins were fixed or not.
True. I remember trying this, though, and in practice all it did was increase register pressure.
Created attachment 9382 [details] add const and pure markers for builtins I ran across the patch I wrote once upon a time. Again, the couple of test cases I looked at regressed in absolute code quality due to excessive register spillage. So applying this may want to wait until we have a new register allocator. Perhaps sometime in the 2010's for gcc 5.0...
Making this depend on the "need a new ra" bug.
Subject: Re: x86 machine builtins do not have any const/pure attributes set > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 04:12 ------- > Making this depend on the "need a new ra" bug. Does the code quality regression still hold even after libcalls was removed? These definitly was one of reason for ineffencities in pure/const function call code generation. Honza > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > BugsThisDependsOn| |18427 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21588 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
(In reply to comment #5) > Does the code quality regression still hold even after libcalls was > removed? These definitly was one of reason for ineffencities in > pure/const function call code generation. I doubt it since these expanded into RTL instruction and there is no call at the rtl level.
Subject: Re: x86 machine builtins do not have any const/pure attributes set > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-30 12:56 ------- > (In reply to comment #5) > > Does the code quality regression still hold even after libcalls was > > removed? These definitly was one of reason for ineffencities in > > pure/const function call code generation. > > I doubt it since these expanded into RTL instruction and there is no call at the rtl level. Hmm, right ;) Should look deper into PR before responding... Honza
Fixed for 4.3.0 by: Author: uros Date: Sat Jul 14 13:46:40 2007 New Revision: 126639 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126639 Log: * config/i386/i386.c (init_mmx_sse_builtins): Define all builtins except __builtin_ia32_emms, __builtin_ia32_ldmxcsr, __builtin_ia32_stmxcsr, __builtin_ia32_maskmovq, __builtin_ia32_loadups, __builtin_ia32_storeups, __builtin_ia32_loadhps, __builtin_ia32_loadlps, __builtin_ia32_storehps, __builtin_ia32_storelps, __builtin_ia32_movntps, __builtin_ia32_movntq, __builtin_ia32_sfence, __builtin_ia32_femms, __builtin_ia32_maskmovdqu, __builtin_ia32_loadupd, __builtin_ia32_storeupd, __builtin_ia32_loadhpd, __builtin_ia32_loadlpd, __builtin_ia32_movnti, __builtin_ia32_movntpd, __builtin_ia32_movntdq, __builtin_ia32_clflush, __builtin_ia32_lfence, __builtin_ia32_mfence, __builtin_ia32_loaddqu, __builtin_ia32_storedqu, __builtin_ia32_monitor, __builtin_ia32_mwait, __builtin_ia32_lddqu, __builtin_ia32_movntdqa, __builtin_ia32_movntsd and __builtin_ia32_movntss as const builtins using def_builtin_const. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c