[LLVMbugs] [Bug 23927] New: CodeGenModule::EmitTargetMetadata() is redundant on all targets but xcore

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Jun 23 07:04:26 PDT 2015


https://llvm.org/bugs/show_bug.cgi?id=23927

            Bug ID: 23927
           Summary: CodeGenModule::EmitTargetMetadata() is redundant on
                    all targets but xcore
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: yaron.keren at gmail.com
                CC: llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk
    Classification: Unclassified

The loop in EmitTargetMetadata introduced in r212263 iterates over all
MangledDeclNames (the module may have 1000s of them), for every one performing
a lookup in the module symbol table and then calling emitTargetMD() which is a
no-op on all targets but xcore.

Hopefully all of this optimizes out in release builds. In Debug builds the code
is still there, slowing down every run as EmitTargetMetadata is always called
by CodeGenModule::Release(). 

This xcore-specific functionality should probably move into xcore target rather
than living in CodeGenModule. At the very least it should bail out early if
target != xcore and skip the loop.

I don't know if this is wrong: EmitDeclMetadata() is called if
(getCodeGenOpts().EmitDeclMetadata) but EmitTargetMetadata() is always called
regardless the flag.

In addition, MangledDeclNames was modified from a DenseMap into a MapVector, a
heavier and slower data structure. If the code is decoupled into xmos target
maybe MangledDeclNames could be DenseMap again.

Finally, this code does not appear to be covered by regression tests at all. If
the whole function is #if 0 *and* MangledDeclNames is DenseMap, regression
tests pass, at least on Windows and Linux.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150623/d51ee322/attachment.html>


More information about the llvm-bugs mailing list