On 07.01.2015 10:10, Michel Dänzer wrote: > On 07.01.2015 06:33, Tom Stellard wrote: >> On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote: >>> On 24.12.2014 02:49, Tom Stellard wrote: >>>> Rather than building a new one every compile. This should reduce some >>>> of the overhead of compiling shaders. >>> >>> Thanks, though unfortunately it doesn't seem to make much difference for >>> piglit for me. >>> >>> >>>> One consequence of this change is that we lose the MachineInstrs dumps >>>> when dumping the shaders via R600_DEBUG. The LLVM IR and assembly is >>>> still dumped, and if you still want to see the MachineInstr dump, you >>>> can run the dumped LLVM IR through llc. >>> >>> Sounds reasonable, but... >>> >>> >>>> @@ -503,5 +510,12 @@ struct pipe_screen *radeonsi_screen_create(struct >>>> radeon_winsys *ws) >>>> /* Create the auxiliary context. This must be done last. */ >>>> sscreen->b.aux_context = sscreen->b.b.context_create(&sscreen->b.b, >>>> NULL); >>>> >>>> + /* Initialize LLVM TargetMachine */ >>>> + r600_target = radeon_llvm_get_r600_target(); >>>> + sscreen->tm = LLVMCreateTargetMachine(r600_target, "r600--", >>>> + r600_get_llvm_processor_name(sscreen->b.family), >>>> + "+DumpCode", LLVMCodeGenLevelDefault, >>>> LLVMRelocDefault, >>>> + LLVMCodeModelDefault); >>>> + >>>> return &sscreen->b.b; >>>> } >>> >>> ... since you pass "+DumpCode" here, the MachineInstrs are actually >>> always dumped unconditionally. With that fixed, this patch is >>> >> >> I've removed the MF.dump() call in the LLVM tree, so this won't happen. > > That won't help people using LLVM 3.4 (or 3.5?), will it?
Tom, users of LLVM 3.4/5 get spammed by MachineInstr dumps with this change, right? Do you have a plan to address this? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev