I don't want to accept any HTML tags. I think I should at least use strip_tags()
Maybe, but not if you want to allow people to type ‘<’/‘>’ characters that just mean less-than and greater-than, and aren't anything to do with tags.
On input for free-text fields you won't really want to filter out much more than the non-newline control characters (which you usually don't want anywhere), and, if you are using UTF-8, invalid/redundant sequences.
Then when you output the value back to the page you will of course remember to use htmlspecialchars() so that ‘<’ gets escaped to ‘<’ and appears as a literal ‘<’ on-screen, right? You need to be using htmlspecialchars() any time you output a text value into HTML in a template, regardless of whether that string came from a form submission, or the database, or somewhere else.
For non-free-text fields where you want all input to match a particular restricted format, then yes, a regexp can be a good way to match this.
and addslashes().
addslashes() is almost always the wrong thing. A good rule of thumb is: don't use this.
addslashes() is inadequate for SQL escaping because it does not match the actual SQL string literal escape format, so you can construct strings that are still dangerous when addslashed. When you're using MySQL, you should use mysql_real_escape_string() instead. Other databases have their own particular escaping functions. Use them (or, easier, use parameterised queries so you don't have to manually escape text to SQL at all).
(addslashes() is inadequate for HTML escaping because it doesn't attempt to do anything with HTML special characters at all. That's not what it's for.)
In any case, trying to cope with output-escaping at the input filtering stage is backwards. Instead, keep all the strings that are internal to your application as plain text, and escape them on the way out of the application: mysql_real_escape_string when they're going out to take part in an SQL query, htmlspecialchars() when they're going out onto an HTML page, and so on.