[llvm-commits] LLVM Verilog Backend

Eli Friedman eli.friedman at gmail.com
Sat Jul 18 14:34:36 PDT 2009


On Sat, Jul 18, 2009 at 4:22 AM, Nadav<nadav256 at gmail.com> wrote:
> Hello,
>
> My name is Nadav Rotem and I am a PhD student at Haifa University. In my
> research (in High-level Synthesis), I developed a Verilog backend for LLVM
> that I would like to contribute to LLVM. The Verilog Backend is documented
> in an academic paper [1].  An on-line web interface is available [2].
>
> I attached the code to this email. The code compiles with LLVM 2.5; I only
> included the Backend itself. I did not include the preliminary
> transformation passes, the driver scripts and the test cases.

Hmm, looks interesting.  A few low-level comments:
1. We clearly can't accept a patch which doesn't compile against
trunk.  Also, once you're at the point of actually submitting it for
inclusion, please submit in the form of an svn diff.
2. The backend appears to use std::string way too frequently.  You
essentially shouldn't need any std::string variables or functions
returning std::strings (with a few exceptions to help Verilog
printing).  For example, you should pass an output stream into the
printing functions instead of having it return a string, and you
should pass around GlobalVariable*s rather than keeping a map from
std::strings to GlobalVariable*s.
3. Try to use efficient data structures.  In particular, you generally
shouldn't use std::set and std::map.  See
http://llvm.org/docs/CodingStandards.html.
4. Static globals are bad.  It's difficult to avoid for the
command-line options, but other stuff should definitely avoid them.
5. The code doesn't follow the code formatting standards in many
places; see http://llvm.org/docs/CodingStandards.html.  In particular,
tabs are not allowed, /**/ comments aren't allowed, code must not go
over 80 columns, indentation must be consistent, and the minimal set
of includes should be used.  Also, I would recommend not indenting the
contents of namespaces; it leads to a lot of extra indentation which
isn't particularly useful.
6. A short high-level overview of how the various classes in the
backend interact would be nice.

Is there documentation for what restrictions there are on the LLVM IR
this backend knows how to process?

In general, I think it would be nice to have this backend in the LLVM
tree, assuming you're willing to do the necessary work to clean it up
for submission and maintain it.

-Eli




More information about the llvm-commits mailing list